Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-02.txt
On Tue, Jun 21, 2022, at 15:09, Eduardo Duarte wrote: > EPP is about 20 years old and I > think it needs some reshaping to the actual Internet state. Is the EPP *transport* really where people struggle most? Ok, XML over TLS might not be the current trendy couple in Internet circles, but among all the problems I see in EPP (having worked both on registrar and registry side), I really do not have the transport in my top 10. The plethora of extensions to do the same thing, and the various "quality" of extensions is more of a concern to me, as well as the non-existent discoverability of features (there is one extension solving part of the problem, not used by everyone). Or the lack of standardization in error codes/messages/details extended from core case. Or the now not good enough design of a contact. Or operations being mixed where they shouldn't (like restore in update). We barely arrived only a few months ago to have "fees" finally being a standard... and it will take years before all registries switch to it. This is certainly where registrars struggle more than just having to use a TLS "socket" (I count around 28 versions of the fees document, for 18 different XML namespaces with more than a couple of them really used in the wild). Said differently, the transport part seems to me really the easy part of the problem of EPP viewed globally. Of course, if that blocks some actors, then the working group is certainly the relevant place to find out a standardized solution, but will really a lot of registries suddenly switch to it just for the sake of switching to it? Or: what EPP over TCP and/or a REST redesign really add as new features, solving current problems? Besides "it looks similar to the rest of the Internet, so it will attract more/better programmers" (a statement I would certainly have an hard time to believe) or "the crappy hosting I am using only allows HTTPS servers/clients and nothing else, so now I have to adapt my whole word just because I chose a bad system from the beginning". Just my personal views of course. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Second WG LAST CALL: draft-ietf-regext-rdap-reverse-search
On Mon, Sep 12, 2022, at 08:54, Antoin Verschuren wrote:
> Please review this document and indicate your support (a simple “+1” is
> sufficient) or concerns with the publication of this document by
> replying to this message on the list.
I should probably have said something earlier, sorry about this.
But I have a concern about §6 Implementation Considerations
as I think it glances over far too quickly on very important points.
I think it can be easy to expect reverse queries to generate "lots" of results,
but then all examples given ("restricting the
search functionality, limiting the rate of search requests according
to the user's authorization, truncating and paging the results, and
returning partial responses.") are not given details, which means there will
be left
to implementors and hence multiple incompatible solutions will emerge which
will make writing
a client more complex, for any case where it has to span multiple RDAP servers
(and then you are exactly in same territory as EPP extensions, too many of them
and too incompatible between them to easily write one client working with all
servers).
There is RFC 8977 "Registration Data Access Protocol (RDAP) Query Parameters
for Result
Sorting and Paging" but it is not even referenced
from this draft.
Same for RFC 8982 "Registration Data Access Protocol (RDAP) Partial Response",
shouldn't
be cited at least as a non-normative reference?
- "restricting the search functionality" does that mean by things related to
the protocol like constraints on `{searchable-resource-type}` or on
`{related-resource-type}` or on `` or by things external to
it, like rate-limit? How will a client discover that it got limited for any of
those reasons?
- "truncating and paging the results": maybe mention RFC 8977 and 8982
- "returning partial responses.": RFC 8982?
But how RFC 8982 would apply here since it is not necessarily the client asking
for limited
data in return but the server deciding to prune them in content or length?
Same question in fact for RFC 8977, that starts with client requesting specific
subsets and order.
I also dislike the mention of indexes here because this is specific terminology
of specific technologies and as such I don't believe an RFC describing a
protocol
should lay any assumption or give constraints on how implementers decide to
implement it.
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Extended Second WG LAST CALL: draft-ietf-regext-rdap-reverse-search
On Mon, Oct 3, 2022, at 08:26, Antoin Verschuren wrote: > 3. Patrick, could you please state that the comments you made during > WGLC are now addressed in version 14 so that Tom can make this > statement? I looked at the newest version, and it seems better, yes. Thanks for the changes to address my previous comments. +1 on the document going forward. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
On Tue, Apr 25, 2023, at 15:54, Antoin Verschuren wrote: > This is a formal adoption request for Extensible Provisioning Protocol > (EPP) mapping for DNS Time-To-Live (TTL) values: > > https://datatracker.ietf.org/doc/draft-regext-brown-epp-ttl/ +1 for adoption as no specific reasons not to have this standardized extension (but curious how many registries intend to implement it) Separately, Two (+1) quick points on the content for draft version 4. Section 8.1 uses twice the same XML namespace for both cases. I suspect `:schema:` is missing in the second one. As for TTL values: The highest bound should be instead 2147483647 seconds. This comes from RFC 2181: > The definition of values appropriate to the TTL field in STD 13 is not as clear as it could be, with respect to how many significant bits exist, and whether the value is signed or unsigned. It is hereby specified that a TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1. This is repeated in RFC 8499 (The DNS Terminology RFC), but it does just quote RFC 2181 again on that. Also the standard uses 0 as minimum value, but I may not argue this is better than 1 in the XML schema :-) Alternatively, personally, I would prefer the value to be given as XML type of "duration". This allows to still pass it as seconds for those that prefer that, but also allows to pass it in more human friendly formats such as number of minutes, hours, days, etc. It does make however stating the maximum value possible more complicated I guess, so maybe not worth doing? Also, not sure if a single TTL value for everything is enough. Are we sure that all registries will be fine using the same TTL for both NS/A/ and DS? If I take `.com` right now, NS has 2 days of TTL, where DS only one day. Curious of registries views on that. HTH, -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] RFC 5731 and Domain Object Deletion
On Wed, May 10, 2023, at 11:57, Hollenbeck, Scott wrote: > RFC 5731 contains text that has led some domain name registrars to > adopt an operational practice of re-naming name server host objects so > that they can delete domain objects. There aren't any other real working methods unfortunately :-( Except in cases of registry fine into letting the host delete go through even if still linked to other domain objects. > There's a risk in renaming the host object, though. If the host is > renamed using a domain that isn't currently registered, such as > ns1.randomfoo.example, it becomes possible for someone to gain DNS > resolution control of ns1.randomfoo.example by registering > randomfoo.example and creating ns1.randomfoo.example. If you stay in same registry, the registrar can just register once for all a "dummy" name like `this-is-really-junkyard.example` and then it renames all hosts below that name. As he keeps registration of the base name, no bad things can happen. With some cost, yes, the cost of one domain only, no matter how many nameservers renamed there. I think the problem is really in the thinking of "let us just use some random non existing name and hope it will work", which created problems as well as the TLD level when people decided to just arbitrarily use `.dev` locally. Also anyway some registries might check that the name resolves at least and hence won't allow non existing domains. There is also the idea of using names below `in-addr.arpa` or other valid suffixes but where obviously no registration happens. Some very widely known names do also provide wildcard behavior to make any name suddenly resolve even if really no nameserver there, and the base name will never go out of existence. > Is this a topic we should address? Do we want to address the generic problem of how to break associations (discussed since EPP existed or even before but as yet no solutions besides renaming or registry forcibly broking the link), or just address what the RFC says to help people do things differently/with more caution? I think the second case can be done, but not really the first. And even so, it is maybe out of IETF scope as it is more an operational matter than really a problem in the protocol itself. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D draft-latour-pre-registration
On Wed, Nov 15, 2023, at 10:56, Jacques Latour wrote: > draft-latour-pre-registration-00 - EPP Pre-Registration Verification > (ietf.org) > <https://datatracker.ietf.org/doc/draft-latour-pre-registration/> Have a look maybe at https://datatracker.ietf.org/doc/html/draft-ietf-regext-validate-04 which seems to cater for similar needs, but for contacts. As such, perhaps one generic extension being applicable for any object types would be better than having one extension per object type. So a new draft could encompass both what you want to do and what regext-validate aims to do. My 2 cents. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-brown-epp-fees: in ?
Le lundi 06 juin 2016 à 06:43 +, Alexander Mayrhofer a écrit : > Neither of the options we came up with is particularly elegant - does > anybody have better ideas? > There is already one extension dealing exclusively with balance handling: http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_balance_v00.html Why not keep the 2 aspects (fee & balance) separated ? Since there are registries not using a prepayment model, hence where the balance has no meaning, but the fee part is useful. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Slight rewording/clarification in §3.4.3 of draft-brown-epp-fees
Hello, I would suggest a slight rewording/clarification of this sentence: If a element has a "grace-period" attribute then it MUST also be refundable. Does that mean 1) just that the client understands that the operation is refundable, without any technical obligation (in the same way as above you have explanations on what the clients should/should not make assumption on) OR 2) that the refundable attribute must be present with a true value? If it is the second case, then there is a slight problem not in this draft per se but the combination of it, plus RFC3915, plus ICANN AGP refund policy (the 10% or 50 domains). Our train of thought currently is to use the grace-period always as we have the information, but not using the refundable one because for create operations we can not compute in realtime refundable=0 or =1 as it depends on monthly volume of registrar activity. Hence my question on the 2 possible interpretations above and basically if the presence of the grace-period attribute implies the presence of the refundable attribute with some value? TIA, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] draft-brown-epp-fee : question on transformCommandType
Hello, This type is defined as such: However there is no text or examples in create/renew/update/transfer commands cases where the presence of a credit node is accepted. So shouldn't the credit element be removed from the transformCommandType ? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Comments on draft-lozano-ietf-eppext-registrar-expiration-date-01
Hello Gustavo, I'm implemented draft-lozano-ietf-eppext-registrar-expiration-date-01 in my opensource EPP client. I have the following comments: - first, would it be possible to switch the document name from eppext to regext? It would be easier to track it since for now, it does not appear on https://datatracker.ietf.org/wg/regext/documents/ (or if it is possible for this page to also track *-eppext-* I-Ds ?) - for the new attribute, "flag" does not seem a very descriptive name. Maybe "sync" instead ? Related to that you've added another layer in the XML structure just to convey this new flag, but then it creates 4 cases depending on the presence or absence of the exDate node below. Shouldn't it be simpler with just a node with a mandatory attribute and an optional (date) value? - since you use the same structure for client commands and server replies, the text in §2.1 does not explain what the server could/should reply, as it is written only from the registrar perspective. Could you elaborate which specific cases the server might use? - there are no examples of the third case of §2.1, that is flag=0 + no exDate node. Could you add one? HTH, -- Patrick Mevzek The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Comment on draft-brown-epp-fees-07 regarding update
Hello, In §5.2.5, the example shows a pure domain:update changing in fact the registrant of the domain, but with a fee extension. This could be technically possible, and some registries may decide one day to make this operation billable. However it is clearly not the common case and the spirit is more towards the restore operation, carried through a domain:update, to be done with the fee extension. Could maybe the XML example shown be of a true restore operation instead of a pure domain:update ? (especially since the introduction clearly speaks about the RGP restore command, and not the update command) -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Comment on draft-brown-epp-fees-07 regarding default domain:period in domain:check reply
Dear colleagues, A question/comment on §5.1.1 of the fee specification: o An OPTIONAL element, which contains the same unit that appeared in the element of the command. If the value of the preceding element is "restore", this element MUST NOT be included. Otherwise it MUST be included. If no appeared in command (and the command is not "restore") then this element MUST have a value of 1 year. Why is 1 year hardcoded there ? Some registries, for some periods and/or some domains, may offer only registrations for some given amount of years, and not necessarily 1. I've already seen registries using 2 years as default and minimum values (hence 2 to 10), and other registries offering some specific values such as only 2, 5 or 10 for example. In short, why hardcoding 1 year here instead of saying that in this case the registries should reply with its default value (the same one that will be used during a domain:create or other commands without a domain:period), which can be any number based on local policies (and may be different depending on the commands, it can be 2 years for create, but 1 for transfers) ? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Reviews, reviews, reviews
Hello, Echoing final comments of Alexander/Jim during the working group session (regarding fostering more input and review forces based on the current amount of documents), I thought that it could maybe help directly if - each registry (domain names or otherwise, since RDAP applies to RIR also) already here on this mailing-list could contact its registrars or some of them, pointing them to the work here, and especially if there are for example EPP extensions that they plan to implement at some future point (or that they may be contractually mandated to implement), so that their clients, the registrars, are aware of that is coming around, and being able to raise their concerns now - and by symmetry, registrars here could invite registries with which they are working to come here, specifically if they see stuff interesting coming in the future and if they want their registry to implement it. So, just a thought if it can help, complementary to all other initiatives that may foster participation. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Minutes for wg meeting at IETF 96 Berlin
Thanks for the minutes Ulrich. About : draft-carney-regext-domain-fees Jody Kolker - presents the extension Please check with draft-brown-epp-fees If the last line is to reflect what I've said, it was in fact some draft from Gavin Brown but not this one about the EPP fee extension (and I've not said it at the mike then, but it was in fact draft-brown- domain-pricing, not submitted at IETF but available on Centralnic gitlab server) HTH, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Reseller Object vs Generic Organization Object
Hollenbeck, Scott 2017-04-03 16:23 > I've been giving some thought to the possibility of writing up a proposal for > a generic organization object that can be compared to the proposal we have > for a reseller object since the topic came up at last week's meeting. […] > We could add an IANA registry for organization identifier types. > > Is something like this worth considering? It looks pretty simple to me. I do agree with your idea, Scott. For me, philosophically it sounds strange to define a reseller object, alongside domains, hosts and contacts, where there is no registrar object. It would look like a missing piece in the puzzle. So having a generic organisation would be useful to code for many cases, and do not emphasize resellers as being a more important objects than others. And +1 for the IANA registry on types/roles. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Clarify on RFC 5731
Ulrich Wisser 2016-11-16 08:23 > Does this mean that it is ok to never return domain:authInfo? I can only say, from experience, that some registries never reply with the authInfo data. For example, with one, as sponsoring client I can send what I want in authInfo, but a domain:info will always show me: hashed While I can understand the intent, I still believe it is not true to EPP spirit and design. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt
Antoin Verschuren 2017-03-03 14:56 > No expressions of preference have been expressed for over a month now :-( > I think the authors deserve good guidance from the working group so they can > progress their drafts, so let me be the first to express my motivation. > I hope we can discuss this in Chicago, so more opinions are certainly needed > on the mailinglist! > > [chair hat off, personal opinion] > > I have a strong preference for option 2, a generic organization object, and a > reseller mapping to such an organization object to identify resellers for a > domain. +1 for me for all the reasons Antoin, Scott and Alex have already said. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt
Gould, James 2017-03-06 21:26 > i. I assume that not specifying the period matches the period that is defined > for the object mapping. In the case of a domain name, the default period > would be 1 year for the create, renew, and transfer commands. The restore > would not support a period, since it is a fixed fee, so there are commands > where the period would not be allowed. I do not agree with "the default period whould be 1 year". The default number of years should not be part of the protocol, since it is a policy item. Some registries may wish, specially at launch time, to use 2 years or 5 years as default period. So, please do not hardcode any value in the protocol, and for example use the same phrasing as the one used in RFC5731 : An OPTIONAL element that contains the initial registration period of the domain object. A server MAY define a default initial registration period if not specified by the client. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard
Thomas Corte 2017-03-29 10:43 > > Yes, the fee information should be returned for a reserved domain if > > pricing information does exist. > > Not sure what this would mean. If a domain is reserved, that usually > means that it's not available for registration under *any* circumstances. I'm not sure about that. A domain name can be on a registry "reserved" list, meaning that it has specific conditions to be available (or not), such as, for one case I know about, trying to acquire a domain name corresponding to a town name, and by default you can not have it (it is reserved) *except* if you give enough (OOB) information explaining why you would be a good custodian for it. So it is reserved in the sense that it is not freely registrable like any other domain names, but it can still be registered with some specific extra conditions. Hence, even "reserved" domain names should display princing, if there is one for them. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Contact Postal Info Elements Proposal
Gould, James 2017-03-31 17:25 > Thanks for the response. My feedback is embedded below. I’ve updated the > proposal based on your feedback: > > > > 1. The sub-elements do have replace semantics > > a.Existing sub-element data deleted first and then set with > updated data. > > b.This includes the , , > , , , and the > elements. > > c.Servers with special policies regarding contact data > modifications should check the new data for any actual changes in relevant > fields. > > 2. The typed elements (“int” or “loc”) are > treated independently > > a.Exclusion of a type (“int” or “loc”) does > not implicitly delete it > > 3. The typed element (“int” or “loc”) is > deleted explicitly via an empty element > > a. or type=”loc”/> > > b.The same applies to deleting the voice or the fax via an empty > element ( or ) > > > > Let me know if any other changes are needed. Hello James, I agree with your mini specification. I would suggest to add some wording about the contact:street nodes, especially if their number changes with the update done. It would probably be superfluous but I believe in this case it is better to over specify things instead of under-specify since this contact:update issue is quite old, so it is a great idea and work to specify it clearly and completely now once for all. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] TLD Phase Discovery
Gould, James 2017-08-03 18:13 > I believe TLD level EPP policies is relevant, but is best suited for > something outside of the Launch Phase or Registry Fee command-response > extensions. An example policy EPP mapping is the Registry Mapping > (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html) > that does provide launch phase schedule information at the TLD (zone) level. > Something like the Registry Mapping with extensions to define the features > and policies of EPP extensions like the Launch Phase or Registry Fee > extensions is best suited for defining and discovering the features and > policies. I agree with Roger that auto-discovery should be a problem to be tackled and replied with solutions. For TLD phases but also for a lot of other "knobs" and options in EPP. And I totally agree with James on the Registry Mapping extension, that could be suited for this task. I would even be very happy if VeriSign could push forward to make this EPP extension a standard, to be used by many registries. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Fee Document
> 1. "avail" attribute meaning on partial return of results, see > section 3.9 for some additional context. The extension allows servers > to choose between returning no results or partial results when a server > encounters an issue with one or more of the requested s. The > question raised specifically was "Should a partial result set the > "avail" attribute to true or false". The intent of the draft was to > return "avail=0" on partial (there was some failure), but some > implementations have interpreted it as "avail=1" (some data returned). > What do people think? Since the client chooses the list of fee:command to include, if some are missing in the reply, I think it means that cd should be zero, because if it is 1, the following sentence, in absence of command elements in reply could lead to wrong conclusions: If the "avail" attribute of the element is true and if no elements are present in a element, this indicates that no fee will be assessed by the server for this command. Basically a complete error to set any fee (because of incompatible request parameters from client) may be interpreted as if no fee is needed at all, which is a completely different case. Hence I am in favor of cd=0 as soon as one problem is detected. The client is free to check again with different parameters until it gets cd=1 > 2. Appropriate level of , see section 3.7 for more details. > There has been an ongoing discussion on moving the element to > the object level (i.e. at the level versus the level). > Currently the draft has this at the level but I do believe in > the merits of the argument that in reality/practice is defined > at the domain object level and not the command level, so unless there > are arguments to keep it at the command level the next version will > move this to the object, , level. I also believe that we talk about a class for a domain and not a class for a command, so it should be tied at the domain level. This is even what the first sentence of section 3.7 implies. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Fee Document
On Thu, Nov 16, 2017, at 09:16, Andreas Huber wrote: > Another solution would be to not transmit standard fees in the fee > extension at all. I disagree. Since the "standard" definition is not constant in time nor in space (amont registries/TLDs), it is not a good basis to omit fees in any case. The extension is here to be as specific as possible, this is cleatly not the good spot to try reducing the bytes count. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Fee Document
On Fri, Nov 17, 2017, at 00:39, Gould, James wrote: > 2. Add a new optional “standard” boolean attribute to the > element, with the default value of “0” (or “false”), that > indicates whether the fees for the command and period matches the > “standard” classification fees for the command and period. I am not very happy with the addition of yet another element. The extension is getting more and more complex. I believe that such attribute is not completely unrelated to the class value, so there is something related to the model that does not feel right to me. This is in fact seen in this sentence: > b. All of the elements for a “standard” classification > domain name, would have standard=”1”. It shows the two values are not independant, so there is a kind of duplication of information. I think that in that case having the class element per command instead of per domain would be a better choice than adding an attribute. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token
needed ":" at end of: the server MUST return an EPP error result code of 2201.: As explained above, I feel uneasy by: Example request command to allocate the domain object with the allocation token: A transfer command does not allocate an object (for me, but maybe it is an error in my English understanding, allocate is a synonym to register in our context), it transfers it. 3.2.5 Same nitpick as previous section, about the extra : at end. Your XML example has a: C: which is probably a copy and paste error. General: Should there be some guidance somewhere that allocation tokens should be unique and not reused accross multiple domains? But then domain:check with multiple domains and only one token are less useful. For implementation status, if you wish you can add the Net::DRI client to the list. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Fee Document
> The classification is defined at the object level, where in general a > domain is either a “standard” domain or a non-“standard” domain (e.g., > “premium”, “discount”), I agree, this was the opinion I raised at the start of this thread. > but there is an issue with non-“standard” > classification objects that is not handled by the element. I am still not convinced by this issue, nor by your solution to it. 2 registrars voiced their concerns on this case, but I would love to hear other opinions, including from registries, to make sure that something new and at the last minute is not bolted into a standard when it does not have widespread need. I am even not convinced that what you propose will help the business case put forward: since the "standard" attribute which is the core of the solution is optional per your suggestion if I read it correctly, registries will be free not to implement it in which case the business case being discussed here will remain without a solution on the field. So we will a protocol with an optional feature for some use case that maybe noone will use. Also, a registry that decides to implement this will have extra work to do for each command (like you said: "This requires the server to compare the “non-standard” classification fee schedule for each specified command against the “standard” classification fee schedule to set the appropriate “standard” attribute.") where maybe no client will be using this attribute (since it is optional, a registrar dealing with multiple registries will need to cope with various cases and know how to behave when the attribute will be absent). In short, I do not see a problem of having a reply with class='notstandard' for a given domain, and then a set of prices associated. Some of the prices there may be the same as some of the prices of a domain with class='standard' (like the case of a setup where creates are at a premium price but not later operations on the domain name). The registrar can make the difference between the two cases, not by comparing prices, but just because the first class will be 'notstandard' meaning that the domain is a premium one in some aspect which is what I understood is the need here. The name of the class could itself convey enough meaning for that. I believe that the extension is clear that the class is per-object and not per-command and hence there is not a standard vs non standard fee, which is clearly what others are attempting to reach. I do not believe you can achieve both goals at the same time. Like you said previously the subject may be too broad and accept multiple representation: I would prefer that we stick to one, which may appeal to some and not to others, instead of trying to accomodate too many disparate or even opposite goals. > If you have another proposal to address this use case, please share it. My proposal is to keep things as is, with the class at the object level. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll
e hosts? The one before or after the transfer? Both? - for out of band domain tests by registry, like technical ones related to resolution - for contacts being automatically purged by a registry after some time of non-use - etc. Implementation status: you can add Net::DRI as a client if you like, it implements all the draft. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] News of draft-ellacott-historical-rdap?
On Tue, Nov 28, 2017, at 12:04, Stephane Bortzmeyer wrote: > draft-ellacott-historical-rdap seems cool and already has running code > at APNIC. But it is also dangerous, since you can no longer erase data > (it is mentioned in the Sceurity Considerations section). > > It was briefly discussed at IETF 99 in Prague > <https://datatracker.ietf.org/meeting/99/materials/minutes-99-regext/> > but nothing on the list, and it expires in one month. Is there still > some interest? Even if outside of protocol design I would be interested to learn more about use cases, especially for a RIR. In the sense that, as soon as such a service/interface exists there will be people, in commercial and non commercial endeavours that will "siphon" out this data to provide it in other services. Not erasing data that could be in part considered as Personal Information would go against a lot of laws, especially now in Europe. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt
Hi Scott, On Tue, Oct 24, 2017, at 14:04, Hollenbeck, Scott wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Registration Data Access Protocol (RDAP) Object > > Tagging One comment on the draft itself. While I think I can understand the need, I still feel very uneasy by the solution of tackling two values together by a given separator. In fact it shows even in the history of the document, where you had to change the separator multiple times. Even beside the fact that tilde looks like a dash inferior lookalike, I think that you would get problems whatever separator value is used. This shows in many sentences of the text. Were other solutions already explored? Like one the following two: - instead of adding the service provider to the current handle, why not having a new RDAP attribute, like handle_provider to store only this value? - or, even more radical, having the current handle element not a string anymore but a dictionary/map with one or two keys, like value (mandatory, would be the current text in the element) and provider (optional). Obviously these 2 solutions involve schema changes so are more difficult to put in place, but I see them are more future-proof. Sorry if I'm late to the game and I revisit already rehashed grounds. Regards, -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt
On Tue, Dec 12, 2017, at 13:19, Hollenbeck, Scott wrote: > I'm just trying to find a simple way to add structure to an identifier I agree, but I believe we have the JSON format to encode structure and hence putting two loosely related items in a string with some separator goes in my mind contrary to the idea of using JSON and departing from all errors that were made with the whois format. If this documents the current practice then it is what it is, but I would be sad this becomes the canonical way to do this in the future. I understand that it is too late to change anything, but I just wanted to voice my concerns. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt
> Think about this, though, Patrick: what the document describes is > essentially how bootstrapping for domain name queries works, too. The > only difference is that the separator is a "." and the operator > identifiers are top-level domains. But in your case the domains are not into some kind of structured format like JSON. Where on the opposite, inside RDAP we have the luxury of the JSON structure. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt
> As a user, I would not want to enter JSON into an RDAP client to do a > lookup. A simple and transcribable string is much easier to use. I never suggested that. The JSON structure is what is exchanged on wire, it is independent on the kind of UI you want to present to your users. > I don't believe the goal here is to define more structure for entity > identifiers. RDAP already provides URLs for entities, and that is > probably enough structure. There does not need to have more structures... as everything is there already I believe with PublicID defined in 4.8 of RFC7483 > All that said, I understand your hesitation here. This draft takes an > unstructured field already in use and applies structure to it. That > could be problematic, and care must be taken. Doing such a thing is not > ideal, but we wouldn't be the first to do so. The xn-- signifier for > IDNs comes to mind. I agree... except that when IDNs were introduced there was already a not so small population of clients (DNS resolvers) that had to be taken into account. RDAP is still young, and far less used than whois. I was amazed to see in fact just by chance that very recently many blogs tried to make it more known, such as: https://blog.apnic.net/2017/08/11/2017-still-whois-whats-holding-back-rdap/ https://www.farsightsecurity.com/2017/11/17/stsauver-rdap/ Like you say, the summary for me is that adding a structure into an unstructured field after the fact is problematic. The problem is on the table, but it may be decided it is irrelevant or too late based on current deployments. I of course agree, I just think it is best to be clear about it. But if noone else speaks about it, case closed. BTW even for DNS, there are also discussions/interrogations showing that changes like IDNs to a core protocol were not necessarily the best choice. See https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/ (a very interesting read for history decisions) -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for adoption: draft-hollenbeck-regext-rdap-object-tag
On Wed, Dec 13, 2017, at 14:44, Antoin Verschuren wrote: > This is a formal adoption request for draft-hollenbeck-regext-rdap- > object-tag > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ > > Please review this draft to see if you think it is suitable for adoption > by REGEXT, and comment to the list, clearly stating your view. > Please also indicate if you are willing to contribute text, review, etc. As stated in another thread, I have concerns about the content of the draft, but I think it is clearly material to discuss inside this working group, so I favor adoption of this document. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token
an not just publish it as a standard and say "the extension is defined in github" There is clearly something to phrase differently here. And I think, in a way, this clearly shows again that the update case for an allocation is very strange. > For implementation status, if you wish you can add the Net::DRI > client > to the list. > > First off thanks for the work on Net::DRI, and we can certainly add > Net::DRI to the Implementation Status section. Can you provide the > following key values to add to the draft or you can also submit a pull > request to the EPP-Allocation-Token-Specification GitHub project > (https://github.com/james-f-gould/EPP-Allocation-Token-Specification.git) > if you want to define it yourself? Ok, I will follow on that separately, thanks. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-dnsoperator-to-rrr-protocol-03.txt
> Working group - are there any other comments or review of this document. I am working on a review for this document. I hope to be able to send it tomorrow. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-brown-whoami-00.txt
On 20/12/2017 12:08, Gavin Brown wrote: > Having thought about this topic for a little while, it occurred to me > that there might be some benefit in a "straw man" proposal for how > centralised databases of registration data might be avoided. So I wrote > this Internet-Draft which describes a simple decentralised alternative > to Whois/RDAP directories. > > Obviously it is far from a perfect solution, but I have yet to think of > any criticism of it that does not equally to Whois/RDAP as they > currently exist. So I have published my draft for feedback. What do you do for domain names that are registered but not technically used, meaning no delegation in DNS? In that case you can not publish URI records in their zone (except if there is a way to have the registry publish it instead in its zone, like it does for glues), nor having a webserver reply for the website under this domain. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
ate detailed after? * 4.2.1.3.1 Nitpick: you use this form "CDS/CDNSKEY" and "CDS/CDSKEY RRset" here, while previously you said "CDS or CDNSKEY record in the child zone" where all of these points to the exact same concept so can you choose one case and apply it consistently in all the document. Also in the introduction you said you are using CDS but CDNSKEY could be swapped, so if that is true, why repeating the duality CDS/CDNSKEY later in the document? * 4.2.2.1.1 "_delegate.@ domain name" This can not be a domain name as those, like hostnames, can not have _ in their labels. It is "just" a resource record. Also for: "Note that the _delegate TXT record is publicly available and not a secret token." Maybe rephrase that as I understand your intent would be to say that no secret value should be used as token for the _delegate TXT record since it is publicly available. * on status codes, is there really a difference between 409 and 412? You use 409 for establishing the trust, and 412 for removing/updating it, in all 3 cases when there is an invalid situation (already DS when starting the trust, no DS to remove when asked, etc.) Wouldn't it be more logical to use 409 or 412 in all 3 cases? * 4.2.2.1.2 " A token is included in the body of the response, as a valid TXT record" This does look underspecified to me. Does that mean that in the body we find the token formatted as a DNS TXT record? In zonefile format or wire format? Or is just the token transmitted, in HTML? JSON? pure text? In the later case, with or without pre and post padding? Also, you specify previously that the token may expire. Wouldn't be nice if in this reply also the expiration would be transmittend back to client? Either as part of the body response (but then you even more need to define it precisely) or an the HTTP level like with Cache headers? For this specific operation, why no 401 case, nor 409/412, nor 429? They should apply also here I believe. * 4.3. Customized Error Messages This is clearly underspecified. How it is formatted in the body of the response? Especially since you later say that it is a protocol for machine to machine communications, so these communications must be framed inside specific structures. * 5. Security considerations You speak about drawbacks without explaining what they would be. * 7. " This protocol is designed for machine to machine communications. Clients and servers SHOULD use punycode [RFC3492] when operating on internationalized domain names." Why do you reference IDNA2003 instead of IDNA2008? Others open point I have not seen and maybe useful to think about: * I believe there should be some kind of recommendation (a SHOULD?) that the registry should notify the registrar of such changes to the domain it may have been instructed to do by third parties, like with service messages in EPP. For at least 2 reasons: internally for the registrar to have locally a relevant state of the domain it manages in its own database, and specially because it could have been an error by the third party/registrant, and also externally because registrars may publish data about domain names they publish (like whois, rdap, escrow exports, etc...) and this often includes DNSSEC data, even if sometimes only a flag enabled/disabled but this still means the registrar needs to be notified of changes it did not start itself. * You advise more than once that the registry should monitor its child zones for their CDS records regularly. What happens if it detects a NS change? Because this may cover two complete differente cases: one where the current DNS hoster just does technical changes and completely manage correctly the DNSSEC setup on both the old and new server, or the second being a change of DNS operator, and the new one not being DNSSEC aware, hence maybe dropping at once all DS/DNSKEY/RRSIG/CDS/CDNSKEY records. What should the registry do? In general, and if it receives a ping through your protocol to update things (a cronjob could have been left running at the old provider for example) * Similar cases if there is a transfer of the domain name... should the trust relationship be reset to its beginnings since in some of these cases this also has the consequence of changing the DNS provider. You in fact barely touch on client authentication in your protocol and saying to me it is outside of the scope seems a little too quick. What happens when the DNS provider changes? How can old accesses be revoked? -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext
s "epp" and "eppcom" schema, and "eppcom" is refered from various domain/host/contact XML schema. - "Organization Extension", and associated "orgext" short name do not seem specific enough for me. Maybe you could try to find something more precise? In fact same problem for the other document. - maybe explain if organization ID are global inside the registry or per registrar; so what happens if registrar X creates an orgnization and registrar Y uses it for domains it manages. === comments related to both === I am more than a little fuzy about your "role" uses. When you create an organization you specify a role, and then when you create/update a domain to add an organization you again specifcy a role. Are they the same or different? Why do they need to be repeated? This whole idea of "role" will need to be seriously improved in both documents. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] org extensions for transfer requirement
Hello James, On Wed, Nov 22, 2017, at 20:11, Gould, James wrote: > As noted previously on the list, we have a propriatary Whois Info EPP > Extension > (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_whois-info_v01.html) > > that provides the basics of the Registrar WHOIS Server, Registrar Name, > and the Registrar URL attributes. The org extensions can be extended to > provide additional registrar-level attributes in support of the transfer > policy. > > Thoughts? While I can see the train of thoughts (and while I completely sympathize with the idea that the current procedure to do transfers is illogical on an high scale even if all small parts are logical), I really do not think that the "org" extension would be a good fit to simplify current problems in transfer procedure, for various reasons: 1) it would mean adding some fields to each organization, that would make sense only for a registrar "role" organization, not for all organization objects; thus these fields would be very seldom populated, and it would make the schema not robust (it would be hard to define it in such a way that such elements are allowed if type=registrar but not with other types) I also remember that this extension was never defined at the beginning for registrars but for resellers 2) from what I recall, there was never a strong support from registrars for this reseller/org extension, as the goal and benefit/drawback comparison was not tilted in the good direction; if suddenly this extension becomes mandatory to conduct transfers, it means registrars would be forced to implement it even if it has a far broader scope than just enabling domain transfers 3) as you state yourself, Verisign already has an extension tailored to that specific need for transfers, and I would far much prefer that this narrowly defined extension gets standardized and used for this specific need instead of trying to bolt the feature onto something that looks close to it but is definitely going after other goals. Part of the current problems in the transfer procedure are in fact not technical but policy related (for example if you come to think about it, registrar R accredited in TLD X, Y and Z would probably have the exact same data as an organization in TLD X, Y and Z databases, or at least its whois server as I doubt registrar will define different whois servers they operate for each TLD they are in; so why is there a need to create this registrar structure in so many TLDs database where only one of them would be enough?). In such cases, no technical solution would make things better, so I believe the "org" extension not to be a good fit for that endeavour, and I advise not modifying it in that direction. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rdap-object-tag-05.txt
Hello Scott, On Thu, Dec 28, 2017, at 15:11, Hollenbeck, Scott wrote: > ...but this isn't really "after the fact". It is, because the RDAP RFCs are already done, and the main reason not to add more structure to them and going the way you propose is that the structure is already done and what you document is what is done on the field. > A minor value change like > this can be done easily in the context of a migration to RDAP. It may mean a small *technical* change but I believe it to be a big *semantic* (design) change and not in the good direction to my thinking. However I think the rough consensus on the issue is clear, so we will remain in a disagreement on this specific issue, but the draft would go along. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext
Hello Linlin, I will wait on next versions of your draft to see how they got changed, but I still have one major point: On Thu, Dec 28, 2017, at 10:58, Linlin Zhou wrote: > I am more than a little fuzy about your "role" uses. > When you create an organization you specify a role, > and then when you create/update a domain to add an organization you > again specifcy a role. > Are they the same or different? Why do they need to be repeated? > > This whole idea of "role" will need to be seriously improved in both > documents. > > [Linlin] Actually the two role have the same value referring to section > 7.3 in draft-ietf-regext-org. I think we need add some words in the org- > ext draft to explain that you should go to org draft to find the role > values. > S: > S: registrar > S: 1362 > S: > > S: myreseller Even with your reply I think I still do not understand enough what you are trying to do with the whole role/roleid/rolestatus things and the fact that it is both an attribute of the organization object and an attribute of the link between the organization object and the domain object. If it is the same value, then one of them is redundant and should be removed I think. I hope to understand this more in your later versions. Do not hesitate to add more text and examples. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-allocation-token
Hello James, > The most likely use case is use of the create command, > but I want to ensure that the allocation token can be used to meet > current and future server policy. I can understand that but then, being too much extensible also comes with its own perils. With the same reasoning, why not extend the renew command also? > There are examples of extending an empty update today in the RGP RFC to > define a new command called “restore”. There is a similar example in > the ConsoliDate Extension > (https://www.verisign.com/assets/consolidate-mapping.txt) to define a > new command called “sync”. These documents define the extension being discussed. In your draft you give an example using an extension not used anywhere nor defined. I still fail to understand that, but maybe it is just me. > Extending of an empty update to define a new command has been > done in prior extensions (both RFC and proprietary), and the allocation > token should support these sorts of extensions. I am not saying that extending the update extension is the problem (while I am still not 100% convinced by the use case, I can accept it technically) I am saying that the example is not clear, as it is using something not even discussed in your document, without explanations. But if it is clear for everyone else, then it is ok. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll
Hello James, >> I am not sure to understand the example for the autopurge. >> If the registry deletes a domain with an immediate purge I expect the >> domain not to exist anymore. But in your example you show the "after" >> state >> and there you have a domain:name and a domain:clID still... but the >> domain >> should not exist anymore. >> In my view you should have the before state with all domain:infDatq, and >> for the >> after state, there should be no domain data anymore. >> I agree it creates a problem as you loose the domain name itself >> in the message, but I still think there should be no domain >> data if it was purged. >> What do you think? > > I thought about this one, and yes this is a grey area. I believe it’s > more important to keep the use of the required “after” state here. The > use of the “before” state is optional and I don’t want to add complexity > by adding support for it here. In this case, the operation is > identifying to the client that the specified record that is included was > purged from the system. On a purely semantic level I still find it wrong to have an "after" purge message reflecting data as if the domain still exists. This will need to be handled by registrars as a specific case, since they could, for example, not always update their database based on the "after" messages because in this specific case if they do it like that they will see the domain existing, where it was deleted. So that message will have a specific handling just for it. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll
On Wed, Jan 3, 2018, at 14:08, Gould, James wrote: > I can add a subsection in section 2 to describe the expected before for > both the create and the delete (purge) to ensure that the servers > implement it consistently and the clients know what to expect. Do you > agree? I think we will agree to remain in disagreement on the subject itself, as you put the protocol over the semantics and I do the opposite. However putting more text and explanations as you suggest would certainly help implementers to better understand things, so this will be welcome I am sure. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Request for Working Group Last Call for draft-ietf-regext-change-poll
On Thu, Jan 4, 2018, at 22:41, Gould, James wrote: > Patrick, > > You will pleased to know that after attempting to write the new section > describing the expected behavior for the state attribute, that I agree > with you. How about the following text for the new State section 2.2? It seems to nicely explain things, so I am happy with it. Thanks for your changes and patience. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext
Hello Pieter, On Thu, Jan 4, 2018, at 19:22, Pieter Vandepitte wrote: > Maybe a bit late as I only very recently started following the list, Welcome to the list then, fresh eyes and minds are always welcome. > Maybe not related to the review of the draft (but related to the draft > itself): What is the purpose of this draft? It seems that it aims to > build a model for all organisations involved in the domain name > registration business, which I doubt there is a need for... But correct > me if I'm wrong :-) Here is some history about these drafts, as a personal opinion and viewpoint, before you go in the archives: - the drafts were introduced to store reseller organization data in the registry, as provisioned there by registrars - there were then extensive discussion and quite a lot of pushback around the question of why reseller data should be stored at the registry; I myself voiced out the philosophical question to see why resellers were suddenly more important than registrars, since the drafts would create new reseller objects in the registry... which still does not have registrars object! - it was then collectively agreed for the drafts to be rephrased in order to sustain coding for any kind of organisation, and not just only resellers; this is where we stand right now - there was a very recent question by James to see if they could be a little extended to add some attributes needed specifically for registrars in order to make transfers in gTLDs simpler/more secure. I am still not convinced that there is a huge support from registrars to store all of this data in the registry, and I have yet to see practical use cases, hence my opinion not being very in favor of them, until at least they make sense to me technically, hence my review. After which standard IETF rules will prevail, so it is for sure good that more registries and registrars voice their opinion, in whatever direction. > So why not stick to that purpose and simply extend the contactAttrType > for contact role with values like "reseller", "proxy", ... and link a > domain to a contact using these new values? If you mean changing the current core EPP schemas, that would mean changing the version, going from epp-1.0 to epp-1.1 or epp-2.0 and that would mean a lot of changes in all registries and registrars. And if you start going that road there are many other issues, small by themselves but not negligible, that could be changed and enhanced in EPP. So, in short, while technically the simplest/fastest case, this is unlikely to happen. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
Hi Stéphane, James beats me for an extensive review of your draft. Here are some of my points however: * I agree on your specific goal of just DNAME and its specific semantic (however you can have other records besides DNAME for a specific QNAME, like RRSIG. RFC6672 §6.1 has a clear example of DNAME+MX) but of course as soon as we add one RR through EPP, as James stated there is the question about all others. There is even already an extension for that. It had URN http://www.verisign.com/epp/zoneMgt-1.0 and I have the code implementing it in my client, but I do not find it anymore on Verisign website. * I would like to see more explanations on what happens if a registrar adds a DNAME on an existing domain name that have in-bailiwick nameservers and hence glues in registry zonefile. Should the change be forbidden (until the registrar removes the nameserver objects) or just the glues just be removed? Then should the nameserver object be deleted too automatically? * Also what happens if the DNAME target is internal to the registry (same TLD)? Should the registry check the domain exists? What if the target has a DNAME record too? * about transfers: you say in your new revision that the transfer may fail if the new registrar does not support DNAME delegation. How would the registry know that beforehand? Clearly outside of the protocol definition, but does that mean there will be a need of specific list of registrars supporting that or not, and a specific "accreditation" I fear this can very soon go into the same rabbit-hole as the case of DNSSEC enabled transfers, and then you have only answers like the keepDS solution in frnic extension, or something along the standard keyRelay extension. * I have mixed feelings about section 10. Specifically you state: A trust relationship MUST exist between the EPP client and server, and provisioning of DNAME delegation MUST only be done after the identities of both parties have been confirmed using a strong authentication mechanism. Does that mean that provisions in RFC5734 (specifically section 8) are not enough to provide that? Otherwise why restating that here? * On issue #3 and the issue of feature discoverability per domain, I do not think the EPP check command is appropriate for that. The DNAME record is not an object per se in the registry data model and hence no operations would apply to it. It would seem wrong to update the domain:check to signal this. I fear right now the best way is for a registrar to just try its create/update and mandate that the registry has a clear error essage in its answer if DNAME is not supported (unfortunately there is no way to extend the protool in that direction -- coincidently I was about to send a draft related to handling of error codes). It could however be a separate and specific other endeavour (auto-discovery of features/capabilities on a fine grained level, per registry object). * On issue #5 I would prefer it stays with EPP terminology, so update+chg (not set) nodes. * On issue #6 I feel it not necessary for the client to explicitely signal it wants the info back for the following reasons: - I expect the use of this feature to be very low, both per registry and per domain inside a registry (but would love to have more data points or wishlists expressed by actors if you have some - you give only RFC7535 as an example and I doubt that AS112 project would hany kind of public domain nam registry attached to it soon) - if this element is present, it is minor in the reply and do not create parsing problems (specifically since its presence is dependant on the login being done with the extension) - I can not really imagine multiple versions of your extension in the wild at the same time (James/you speak about -01 vs -02), do you have a specific idea in mind? If you really want to signal no data in all cases, you can also reply with an empty dNameTarget (but I am not sure it is useful: in the same way for a DNSSEC enabled domain, if there as no DS/DNSKEY records attached to it then you do not get the extension in the domain:info and everything is fine, and the client does not specify anything in its domain:info command) HTH, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Sat, Jan 6, 2018, at 20:01, Patrick Mevzek wrote: > - I can not really imagine multiple versions of your extension in the > wild at the same time (James/you speak about -01 vs -02), do you have a > specific idea in mind? And even in that case the client would surely at login specify only one of the two versions so the answer would reflect that. Expect if -02 is not a superste of -01 and introduce a completely different datamodel... -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
On Fri, Dec 22, 2017, at 07:03, Patrick Mevzek wrote: > Hello authors, > > Please find below my review of your draft. Please also have a look at https://tools.ietf.org/id/draft-hildebrand-deth-00.txt as it covers related goals (it is more generic than just NS/DS needs) I do not know where it is discussed nor its current status. It may however be of interest to this WG. Stéphane, it does not speak about DNAME, but since it lists CNAME/NS it could be a trivial addition. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] org extensions for transfer requirement
On Tue, Jan 2, 2018, at 15:11, Gould, James wrote: > I believe the only fields missing include the > reference to the RDDS services (WHOIS, RDAP). To keep the organization > generic, this could be defined as a list of servers that may be set for > an organization. This list of servers will have absolutely no meaning for organizations not being registrars. So the extension cease to be generic. > I’m not asking or proposing a requirement to implement the org > extensions, (I fear however that this could be a future outcome, if the use of the extension becomes mandatory to conduct transfers). > but asking whether with the org extensions over the secure > EPP protocol would be a better option than registrars getting > information from the registries via an insecure channel that may become > further restricted. I am not saying the contrary, but: - I think that the feature can be done otherwise/by other extensions - I do not want this extension to be suddenly perceived as absolutely mandatory because it is tied to the proper handling of transfers between registrars. I note that there was never a suggestion in the past if my memory works to introduce an extension to store registrars, so maybe the need to do that to better handle transfers was not obvious. There was for resellers, and then later it transformed into a generic organization handling. > If the registries do have the registrar > information, then why can’t the registries provide the information over > EPP to the registrars to support transfers? They sure can. And maybe should. But we lived many years without that anyway. > Why would you propose to create many small, targeted extensions to cover > specific use cases instead of leveraging a more generic extension that > is itself extensible (e.g., roles and servers) to support many use > cases. I'm inclined to the Unix philosophy of having many small tools that you can compose to produce what you need instead of a monolithic one trying to cover all cases and finally not being good in any case. I am not proposing to create other extensions because, as you already stated there is already one extension existing covering exactly the use case you are speaking about. As I said previously I would far more favor works towards making the existing extension a true standard used by multiple registries. Does Verisign plan to stop using its own extension and using instead the generic organization one we are talking about here if it includes the changes related to registrars whois/rdap servers? > I agree that the registrar information is best defined in a central > registry as opposed to be replicated to each of the registries. So I think this is the true issue to tackle but probably outside of this working group charter and also far more difficult, as not only purely technical level. I would theoritically prefer to see more energy spent on solving this issue at a generic level instead of hoping to solve it just with an EPP extension. > I believe > the point is that the registrars may need to know the sponsoring > registrar information to support the transfer policy, and the org > extensions provide the most secure and stable mechanism for this. So you are saying that the current EPP WhoisInfo extension designed to help registrars conduct transfers is not suited to do that? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Mon, Jan 8, 2018, at 14:51, Stephane Bortzmeyer wrote: > > * I have mixed feelings about section 10. > > It is copy-and-paste for RFC 5910, which is on the standards track. You are not the first one giving me that explanation when I do a review. I think however this is a weak argument. Even perfect RFCs have errata and are then later on obsoleted by other RFCs. So nothing is set in stone, and if there was an error before or anyhing that is just copied from one RFC to another this does not make it true and not questionable again. This is why I was asking you, as author, if you are behind the sentence you wrote, and if so if you can explain why it is mandatory. Because I do not understand it. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting Invite
On Mon, Jan 8, 2018, at 17:11, Roger D Carney wrote: > For agenda 1.a we will be making the decision on how works > (command or object level), so for those that have an opinion on this > topic, this will be the last time to discuss before the document is > updated. I will probably not be able to take part of the meeting for technical reasons, but I hope that you would also take into account prior discussions by email on this topic. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting Invite
On Mon, Jan 8, 2018, at 16:55, Gould, James wrote: > Roger and I are currently working on an Internet Draft that is based on > the Verisign proprietary Registry Mapping extension at > https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v01.html. > James, If interested, I would be happy to work on that too, as I have some ideas for it on how to use it for discoverability of other things in the framework of an EPP exchange, as well as properly handling all future extensions that may themselves need something like that. So let me know if you could use some help. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Mon, Jan 8, 2018, at 14:51, Stephane Bortzmeyer wrote: > On Sat, Jan 06, 2018 at 08:01:02PM +0100, > Patrick Mevzek wrote > a message of 77 lines which said: > > > as soon as we add one RR through EPP, as James stated there is the > > question about all others. > > Yes, and I clearly do not want to go into that: too complicated for > me. Have you seen draft-ietf-dnsop-aname? Seems to be closely related in the sense that it could be as useful to have DNAME as to have ANAME (of course the difference is that one already exists the other not yet or never) > > There is even already an extension for that. It had URN > > http://www.verisign.com/epp/zoneMgt-1.0 and I have the code > > implementing it in my client, but I do not find it anymore on > > Verisign website. > > It is not in the IANA EPP extensions registry either. There are many EPP extensions in the wild not in the extensions registry. > > * On issue #3 and the issue of feature discoverability per domain, I > > do not think the EPP check command is appropriate for that. The > > DNAME record is not an object per se in the registry data model and > > hence no operations would apply to it. > > The idea was not to use the DNAME record as the object but the domain > name, with an extension. Something like: > > example.com >foo.bar.example.net > I am not sure you could easily extend the current core EPP to do that. AFAIR I have never seen an extension like that. > > * On issue #6 I feel it not necessary for the client to explicitely signal > > it wants the info back for the following reasons: > > I agree also. > > > If you really want to signal no data in all cases, you can also > > reply with an empty dNameTarget > > Note that it is not permitted if we switch from EPP string to > eppcom:labelType. Except if you derive from it and/or you have a different type for update than for create. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Tue, Jan 9, 2018, at 16:32, Stephane Bortzmeyer wrote: > And, anyway, my first use case was only for the root but I don't see > the point of hardwiring this specificity in the draft AFAIK there is no (not yet?) IANA EPP server to which TLD operators are clients, so how would they use the extension to signal to the root to have one TLD being a DNAME to another? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting
On Wed, Jan 10, 2018, at 21:51, Roger D Carney wrote: > Good Afternoon, > > We held an interim meeting today January 10, 2018 and discussed the Fee > document. Thanks Roger for the summary. > We did not make it to discussing the Registry Mapping, we will plan to > have a follow-up meeting to introduce and discuss this topic. AFAIR this point has not been discussed on the mailing-list. Could it start there maybe first? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] EPP and DNAME records?
On Sun, Jan 14, 2018, at 20:31, John Levine wrote: > There's little reason to put an ANAME into a TLD zone file. Stéphane's draft is not tied to any level of the DNS tree. My comment was in that sense and based on previous discussions of various RRs in EPP extensions. > With respect to DNAMEs at the top level, someone else noted that the > root zone isn't managed the same way as TLDs, I think that would be me. > Since you can get the effect of a DNAME in the root zone > by putting a DNAME at the apex of a TLD as Taiwan has done, if people > want more root-ish DNAMEs it might be more productive to consider how > to invent a policy to allow a DNAME-only TLD if you're not a ccTLD. But this won't be ontopic in this WG. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] first reason not to do EPP and DNAME records?
On 2018-01-15 14:31 -0500, Ulrich Wisser wrote: > I might be mistaken, but I believe that IANA sends root updates to > Verisign via EPP. Yes. See page 5 of https://archive.icann.org/en/meetings/seoul2009/bitcache/IANA%20Update%20-%20Kim%20Davies,%20IANA-vid=7506&disposition=attachment&op=download.pdf and https://www.ntia.doc.gov/files/ntia/publications/root_zone_administrator_proposal-relatedtoiana_functionsste-final.pdf The current automated RZMS replaced the legacy root zone update, validation, extraction, and distribution methods with a web based user interface (UI) that permits Top-Level Domain (TLD) managers to submit change requests , an Extensible Provisioning Protocol (EPP) client and server system that communicates incoming root zone change requests between the IFO and the RZM, [..] (IFO=IANA, RZM=Verisign as DNS root operator) -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [art] New Version Notification for draft-hardie-iris-arpa-00.txt
On 2018-01-25 10:20 -0500, Andrew Newton wrote: > My understanding is that DCHK did get deployed by two domain > registries. I do not know if they still use it though. It was deployed by .DE and .FR .DE stopped it on December 2013: https://www.denic.de/en/whats-new/news/article/shutdown-of-domain-check-dchk-lookup-service-as-of-3-december-2013/ .FR still runs it (without any plan to stop it for what I am aware) I am not aware of any other domain registries deployment. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Comments on "draft-sattler-epp-registry-maintenance-02"
cially for important cases. It should be useful to be able to put this somewhere in the maintenance details maybe? - How would your extension code for the fact that some maintenances for example would make EPP read-only, the registry would accept all queries but only act on the ones not modifying objects? Maybe a new impact value like 'read-only'? How to code a maintenance that "only" degrades performances? - I think you should also have a look at usual past cases of maintenances. For example: global change of passwords because of a breach, registry ramp-up such as a cut just before entering GA for example, EBERO switches maybe? etc. - I would like a discussion on OT&E systems too: do they have notifications? If so, where? (because registrars may not poll on OT&E systems so it may make sense to publish OT&E maintenances even on the production EPP server). -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-rdap-object-tag-00.txt
On Mon, Feb 12, 2018, at 15:29, Hollenbeck, Scott wrote: > There's been no comment on this document in the month since it was noted > on this list. Does anyone have anything to say about the proposed > practice? I have not specifically commented this version, but all my old comments apply to it the same way and the previous thread ended with clear positions on both side so I do not think there is anything to rehash. In short, I am happy if current practice is documented, as such. (It would however have been great seeing more support from other RDAP server operators) I am not happy to have that set as a new standard/recommendation. (and even less by the ~ character choice, but this is bikeshedding deriving from what I think is the core problem: putting structure inside a non structured element while all the surroundings being JSON is structured). -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] draft-ietf-regext-epp-fees and standard attribute
Hello, I do not know if you already discussed this in London, but the addition of the standard attribute in this latest version of the fees draft lacks any explanation. The standard attribute, besides in the XSD, appears nowhere, except in this sentence: The element(s) contain(s) a "name" attribute (see Section 3.1), an OPTIONAL "standard" attribute with a default value of false (0), an OPTIONAL "phase" attribute, and an OPTIONAL "subphase" attribute (see Section 3.8). Note that all elements are explained by giving references to other sections with details, except the optional "standard" attribute. I do not believe that such a description is enough in a specification. So some explanation text will need to be added here or elsewhere in the document to describe how the answer changed based on this attribute presence or absence and its value. I would specifically think that details on its working regarding this other sentence of the document will be needed: Servers which make use of this element MUST use a element with the value "standard" for all objects that are subject to the standard or default fee. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Other comments on "draft-ietf-regext-epp-fees-10"
Various other points while re-reading the draft.
*) Non-optional attributes should have
use="required"
in the schema, especially for those not being a string.
*) nitpick
"(e.g. not accepting registrations or applications)the server MUST"
space missing after the parenthesis
*) grammar
"All returned failed
elements that MUST have a element
detailing the reason for failure, "
"that" should probably be removed there
*)
" When the query command has been processed successfully,
the client included the extension in the command service
extensions, and the client is authorized by the server to view
information about the transfer, the server MAY include in the
section of the EPP response a element,"
the part "the client included the extension in the command service
extensions"
reads strange to me on two grounds, this sentence itself and its place in the
whole
block.
I suggest:
" When the query command has been processed successfully,
if the client has included this extension in the command service
element, and if the client is authorized by the server to view
information about the transfer, then the server MAY include in the
section of the EPP response a element,"
--
Patrick Mevzek
p...@dotandco.com
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-change-poll-07.txt
On Wed, Jan 31, 2018, at 18:11, Gould, James wrote: > Yes, 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. So, to > clarifying for the list, there are 4 options that include: I favor option 1 (return the extension independent of the login services) from your list. And now for my detailed rationale about that: - the list of extensions at greeting/login time do not convey enough semantics, like for example which extension is mandatory for login (especially complicated when the registry offers at the same time multiple versions of the same extension). The registry can only react by refusing the login, hopefully with a good enough error message, but nothing is guaranteed here. So for now, this kind of information is lost in documentation (James, another useful data item to have in the Registry Mapping in fact). - the registrar has to specifically acknowledge a message, after having seen it; so the responsability is on him. - poll results, aka notification messages are by definition not real time: a registrar could as well download them all, store them locally in some way and parse them later, including later when he has a software capable of understanding them - some registries let registrars choose, out-of-band, which kind of notification messages they wish to receive; hence when this feature exists it should again be the burden of the registrar to make sure it receives the notification it needs to receive. - giving the registrar all messages, irrespective of its choices at login time, is also the case giving less work to the server. > 2. Return an Error (e.g., 2307 “Unimplemented object service”) to > Poll Request for Unsupported Poll Message This would be hugely detrimental for registrars because this would block all of their queue for one message about something maybe that they explicitely do not care about and have not implemented the relevant extension. > 3. Return a Successful EPP Poll Response with an Extension Element > that Indicates Lack of Client Support If this means the original message is lost, I think it is a show stopper. And if the registrar was not inclined to code a parser for some registry notification that forces the registry to respond with this case, why should we imagine that he would have coded the parser for this new extension also? > 4. Return a Successful EPP Poll Response with an Encoded > Element Indicating Lack of Client Support Same remark. Also is defined as a human-readable element content, hence I do not think it is good to overload it with other data in it formatted in some way. XML is a format, if you need to carry some formatted things it should be using XML elements/attributes, and not be serialized in some way in a string element. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Registry Maintenance Notifications for the EPP
this specific extension, whereas just having another poll notification result does not mean implementing anythin on the protocol level, just the parsing of a new message type. I believe that maint:list is underspecified. What are "all maintenance notifications"? Only future ones or really all of them, even from the past? Does that include ongoing ones? Only active ones? For registries having fixed maintenance slots (like sunday 6AM, each sunday), how should they handle that? They would obviously need to limit the amount of future maintenances to return. * 4.1 Schema - I see both start and end are optional. What is the meaning of a maintenance without a start? Without an end? Without a start and without an end? - The status list here is active and deleted, where the text speaks only about active and inactive, so there is a discrepancy. - You changed maint:remark to maint:detail in the text, but not in the schema Also since you say there are URLs, why not choose something more specific than token for its type? * Other generic comments/ideas - Some maintenances may be a follow-up, a fix, or a reply to another past maintenance. It may be useful hence to add a parameter (optional) in a maintenance data that would reference a previous maintenance id. - Also registries may provide specific point of contact during the maintenance, specially for important cases. It should be useful to be able to put this somewhere in the maintenance details maybe? - How would your extension code for the fact that some maintenances for example would make EPP read-only, the registry would accept all queries but only act on the ones not modifying objects? Maybe a new impact value like 'read-only'? How to code a maintenance that "only" degrades performances? - I think you should also have a look at usual past cases of maintenances. For example: global change of passwords because of a breach, registry ramp-up such as a cut just before entering GA for example, EBERO switches maybe? etc. - I would like a discussion on OT&E systems too: do they have notifications? If so, where? (because registrars may not poll on OT&E systems so it may make sense to publish OT&E maintenances even on the production EPP server). -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-fees-11.txt
On Wed, Apr 11, 2018, at 22:24, internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-11 I see that this includes some of my latest comments (but not all of them, for example required attributes still do not have use="required" in the schema, and I have not seen an explanation about that), so thanks for taking them into account. However I still think there is a big problem for the "standard" attribute. For me even this new version does not define it really. Where it appears it says now: The element(s) contain(s) a "name" attribute (see Section 3.1), an OPTIONAL "standard" attribute with a default value of false (0) (see section 3.7), an OPTIONAL "phase" attribute, and an OPTIONAL "subphase" attribute (see Section 3.8). The element(s) MAY have the following child elements: so it references the section 3.7, which is new. But the problem is that this section only speaks about classes and the element in responses. There is again nothing there about the "standard" attribute of a in requests. There is specifically a need to explain things in relation to last line of this section. What happens/What does it mean/Is it allowed or not when fee:class=standard but standard=false or when fee:class=premium but standard=true? Especially since both elements are optional. I believe that this lack of explanations can cause major interoperability problems, even more so because this attribute was added very late in the draft lifecycle. Maybe people in favor (I am not) of this attribute should chime in and provide some useful text to add in the specification. I do not think it can pass LC without this fixed. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag
On Fri, Apr 13, 2018, at 12:54, Hollenbeck, Scott wrote: > It's OK to say, "I've read the > document and I have no concerns"! The IETF doesn't charter "lurking" > groups, people! FWIW and speaking just about myself, it is not that I am just lurking in the LCs it is that I have various issues with the 4 current LCs (this rdap-objet-tag, the fees one, and the two organization ones, though I need to carefully re-read these last 2 to implement them and see differences), for which I already raised concerns here that were or were not adressed. So I can not support them, and this is why I say nothing, and while objecting to them at various degrees, I have no strong enough feelings to be vocal about them. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-fees-11.txt
On Fri, Apr 13, 2018, at 15:09, Gould, James wrote: > I made the proposal for the optional "standard" attribute with the list > message > (https://mailarchive.ietf.org/arch/msg/regext/7E6X5xCdt3DhqL7p7CFupm9bAAY/?qid=e4f712bc8e70e4d0a458971928924651) > > on the thread with Pat Moroney. Yes, but that was not included in the document and noone replied to your request for thoughts. > The description in the proposal was " > Add a new optional “standard” boolean attribute to the > element, with the default value of “0” (or “false”), that indicates > whether the fees for the command and period matches the “standard” > classification fees for the command and period.". To address your > concern, how about revising the description to the following: > > ..., an OPTIONAL "standard" attribute with a default value of false (0) > that indicates whether the fees for the command and period matches the > "standard" classification fees (see section 3.7), ... Maybe it is just me, but I still think that for someone new (or even not so new) this is confusing. If client stays standard=false does that mean that the reply can not have class=standard? On the opposite with standard=true, should? must? the reply have a class=standard reply? This all seems under specified to me. > In hindsight this attribute should have been exclusively included in the > of the check response (XSD commandDataType instead of base > commandType) since I believe it's only provided by the server, but that > would require a schema change. The definition of the attribute may have > to be moved as well to the check response command description. The fact that there is a need to change the schema at the last time clearly shows to me that something is half-baked and should not be shipped as is. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-allocation-token-06.txt
On Fri, Apr 13, 2018, at 11:05, Pieter Vandepitte wrote: > Short question: what's the purpose of an allocation token within a > transfer command (and what's the difference with authInfo code)? I > understand the purpose in case of create and I can imagine some use > cases for update, but even for update, I have my doubts. You are right and I share your surprise and doubts, about both update and transfer. update has been removed, transfer is still in the draft. > I'm sorry if this question has been asked in the past, but Google > doesn't appear to be my friend today ;-) The same area of concerns were raised at least by Alexander Mayrhofer here: https://mailarchive.ietf.org/arch/msg/regext/HgPkOGl0rVNwVZ9L8_37U1uS76o and previously by myself here: https://mailarchive.ietf.org/arch/msg/regext/LnvUUbjWzdez1MyHKDbPwkoywt0 and the threads following them. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
On Mon, Apr 16, 2018, at 16:03, Gould, James wrote: > Thanks for your thoughts of the 4 options presented for handling the > returning of a poll message that the client does not support based on > the client login services. To note, this is not specific to draft-ietf- > regext-change-poll, so it is an important topic for defining a generic > solution for all poll messages. I agree, hence: 1) I change the subject 2) I am also wondering if we are not overdesigning something: obviously this problem exists since the beginning of EPP and can only have grown much worse with the additions of new registries, new registrars and new EPP extensions... but as far as I know this subject has never been discussed and no registrar came complaining about the issue So, for this reason I am still inclined more toward "do nothing" and let the registrars get all messages and deal with them. > I re-reviewing the options, I believe > option 4 is the only option that is protocol compliant We will remain in disagreement. > For option 4, I propose to > define a simple ABNF formatted message that indicates what > poll message service namespaces (object or extension) are not supported > are therefore not returned by the server. I still stand the position that is defined for human consumption and hence any "formatting" in it is at least violating the spirit of the protocol. So I do not support that. > A poll message may include > multiple EPP services (object and extensions). It would be up to the > server to filter the services not supported by the client and add the > service namespace to the encoded element. So you are proposing that: 1) all registries change their software (filtering messages) and 2) all registrars change their software, to parse the special format in I fear that this a lot of changes, and I am not really sure you can count on them. And starting with "registrar X did not implement parsing of messages in namespace Y" you arrive to a solution that is "registrar X must parse specific content inside ". If the registrar was not convinced to do the first point, I am not sure it will get convinced to do the second one anyway. Hence I still think the status quo is better and let the registries send all messages. > JG-I don’t believe the server returning something that the client does > support based on the login services as being protocol compliant. There > is the issue of the message becoming a poison message for validating > clients. The Verisign EPP SDK does support XML schema validation of the > responses by default, where the server returning an XML namespace that > is not configured on the client-side will result in an XML parser error > and result in a poison poll message. This is only one implementation possible. Like I said previously, since these messages are by definition not realtime I see no harms (and only benefits) for the registrar to get all messages, store them, and parse them later. In that way there is no poison message, and full dynamic support of all namespaces. > The XML schema validation can be > disabled, but it really should not need to be disabled if the server is > protocol compliant. Validating poll messages do not need to be done in real time inside the transaction. It can be done asynchronously outside of it. > JG-I agree that creating a new extension for this runs into the same > issue of the client not supporting the new purpose built extension. I > don’t view this as a realistic option. You are creating a "mini" extension by embedding some format inside the element. > JG-I agree that this is not perfect, but it is the only option that is > protocol compliant, that will not result in a poison poll message, and > will enable the server to convey to the client the XML namespaces of the > services (object and extensions) that they can request the attributes > out-of-band using the message id. I still think that sending all messages and letting the registrars validate them out of the EPP session is the simpler solution. Also, like I said, noone complained on all of this since EPP started, so maybe affected registrars and registries should speak up... -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-fees-11.txt
On Mon, Apr 16, 2018, at 16:19, Gould, James wrote: > On Fri, Apr 13, 2018, at 15:09, Gould, James wrote: > > I made the proposal for the optional "standard" attribute with the > list > > message > > > (https://mailarchive.ietf.org/arch/msg/regext/7E6X5xCdt3DhqL7p7CFupm9bAAY/?qid=e4f712bc8e70e4d0a458971928924651) > > > on the thread with Pat Moroney. > > Yes, but that was not included in the document and noone replied to your > request for thoughts. > > There were plenty of responses on the thread to the request for > thoughts. See Pat Moroney's response that is next in the thread > (https://mailarchive.ietf.org/arch/msg/regext/ftCDAgAQMyXDPPbvKYN3px5cG_Y). Sorry I trusted the web interface of the archive, and it does not display threads nicely. I should have trusted by own email client instead. > The fact that there is a need to change the schema at the last time > clearly > shows to me that something is half-baked and should not be shipped as is. > > Do you support the inclusion of the "standard" attribute I do not and said so in the past: https://mailarchive.ietf.org/arch/msg/regext/HY1aRTOvT0om6IL4vP6EgBoQaT4/?qid=46a1b6e6f1f01ab50b68a5f44c48f5cf I think its addition only create more complexity without a real use case. The fact that it has no clear definition in the current draft seem to prove that. > There is no need for the client to specify the "standard" attribute in > the check command. It is the way it is currently defined. The proponents of having it in the client request should maybe say something. But I see no more reasons to have it in a reply: class=standard already conveys the meaning. In short, if someone cares for this, in the client request and/or in server reply, they should provide specific and detailed definition in the document. If there is noone willing to define this element clearly in the specification, I think it means that it need to be removed altogether. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-allocation-token-06.txt
On Mon, Apr 16, 2018, at 16:56, Gould, James wrote: > Patrick, > > You are right and I share your surprise and doubts, about both > update and transfer. update has been removed, transfer is still in the > draft. My phrasing was poor/too quick, sorry about that. Let me try to rephrase: I was surprised and I had doubt when I first read the specification and see the use of transfer and update commands. I think that any new reader of this specification may have the same surprises and doubts on these points. We did discuss it, yes, and you removed the update, notably after Alexander review. So the case is closed for me. > I certainly don't recommend allocation via the transfer, but I'm aware > of use cases where it has been done. This is all that is needed to support its definition in the specification. > It is not the place for the > protocol to dictate the policy. If you feel that it must be removed, > please make a formal request to the list for it's removal and the list > can discuss it. I have different views but I also do not have the use cases you see in front of me so in any case my own personal opinion has no weight. As a shepherd for this document, my goal is to advance it in the IETF path now, and discussions did already take place, so I will not restart them (other participants are of course free to do it if they wish). -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag
Pieter, On Mon, Apr 16, 2018, at 15:39, Pieter Vandepitte wrote: > No, indeed it isn't about discovering entities, but discovering the > authoritative server for an entity, basically wat is meant with > bootstrapping. [..] > So my final vote on this draft: if there's a need for "globally unique > handles" (I'm not convinced they are needed to help the clients), then > yes, go ahead, but I would prefer a hyphen (it works, as long as the > repos do not have hyphens), the same as roid in EPP. FWIW, note that I completely share both your observations and your conclusions. So that you do not feel alone :-), we are at least too, but clearly the minority. Such is life. More broadly, I am doubly sad that hyphen is rejected because already seen elsewhere. First, because RDAP for domain names has not reached critical mass and far from it in fact (newer discussions on GDPR should have ressuscited it since it is clearly suited for it, but things being done at the last time did not make it possible I guess to think about it, and I applaud Scott's energy and experiments on authentication models for it), so no characters should be ignored just because some other registries did start to use it. When IDNs started, before IDNA became a standard, names were sold and used with the bq-- prefix. This was absolutely not a reason not to choose a "proper" prefix, even if it meant at the time to break any existing bq-- domain names Secondly, not using hyphens will make it very hard for anyone to convince me that there is really an overlap between EPP and RDAP (which was a core justification to create this WG), as hyphen is clearly the choice in EPP. The rdapConformance part could have a "objectTag-0" token whose presence would signal the client that the hyphen in object IDs has a special meaning because it is a separator. This would allow current registries using hyphens not as separator to continue working in the same way as they would not present this "extension" in their response. Client would just need to adapt, but it is the case what ever happens and characters is used since there is no guarantee that all IDs, even in the same repository, will be formatted with it. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-rdap-object-tag
On Wed, Apr 18, 2018, at 13:07, Hollenbeck, Scott wrote: > This is worth exploring. What do people think about going back to HYPHEN > MINUS as a separator and noting the significance of the character with > an "objectTag-0" token in the rdapConformance array? The draft should > probably include text requiring addition of an "objectTag-0" token in > the rdapConformance array to note support for this practice no matter > which separator character is used. Whatever character is used, I think it creates no harms and only benefits to put something (whatever token is best) inside the rdapConformance array to signal to clients that object IDs are returned with some specific format, so that they are aware of it. And things remain compatible with current registries not using a specific format and hence not adding this token. -- Patrick Mevzek p...@dotandco.com ___ 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)
te a draft and let the WG consensus build itself on it, if it reaches other interests. I am certainly not here to say not to do it. I have no counter proposal to yours since my solution is basically "do nothing", as the status quo, while not perfect, seems good enough to me or at least best than the solution we speak here about. But of course it would help if registrars specially come and share their experiences and "wishlist". So, feel free to go forward with a draft if you like. > 2. Server considers the login services and filters non-supported > extensions (object and command / response) from the poll message > response with an encoded indicating the extension namepaces > not supported. This also raises an another important problem, partially depending on policy. Let us imagine the registry starts some new notification messages under a new namespace (or, less radical: just changes some namespace version). At the exact moment this happens all currently logged in clients, as well as all future clients not having been updated will know nothing about this namespace hence, per your proposal, the server will filter out these messages. Where will these messages go? If they are lost for good it is bad as the registrar will have no way to know that (except parsing in a new way the msg element, which involves updates), at all. Even maybe no way to know it needs to be updated (whereas if it started to receive new messages it would just see the new namespace and could act or error on it, but at least decide itself what it wants to do). Maybe the client will just get updated hours or days later, but even in any tiny timeframe some messages may come like that and be lost forever... (the registrar can not necessarily wait on the first of such message by not acknowledging it until it gets updated, because this will block it from retrieveing the following ones, that may contain even more important information for its business). I think this is taxing registrars too much. You suppose also that the registrars will get updated to parse the new format: this is an assumption that can break. Filtering messages at the server side seems creating more problems than solutions to me. This is tied to the problem of sitting messages not being acknowledged by the registrar. Some registries are then sending them by email for example after a certain delay to be able to purge the queues. I know others where there is no purge and you can find messages almost 10 years old... (the usefulness of such messages now is seriously debattable...) But at least not just filtering some out and making them disappear definitively. -- Patrick Mevzek p...@dotandco.com ___ 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)
On Fri, Apr 20, 2018, at 16:06, Gould, James wrote: > Thank you for the detailed description of your reasoning. I will leave > it that we disagree on the purpose of the login services, the need for > the server to honor the login services for poll messaging, and the > impacts in returning unsupported responses or response extensions to > clients. Ok. > On the impact, there are two elements to consider including > first the XML parser in validating a response against the XML schemas, > and second is the unmarshalling of the XML to a representative object. > A client could disable the XML parser validation and move along to the > unmarshalling step. In the unmarshalling step the client would need to > deal with receipt of unsupported content. The client could throw an > exception because the XML (e.g., DOM tree) could not be unmarshalled, > ignore the unsupported content, or come up with some other > representation of the unsupported content (e.g., convert to list of XML > blobs or DOM objects). A client would need to proactively deal with the > unexpected if the server does not honor the login services of the > client. Your description still leaves out a case, that I can not prove to be the dominant one but that is certainly not a negligible one: the client receives the message, DOES NOT validate it per XML schema, DOES NOT parse it, and just stores it (as is or with a simple transformation to any other serialization format, an operation that does not need to know about the schema nor the content at all) for out of band later examination, and ACKs it in EPP to be able to fetch the next one. In this case, there are absolutely none of the problem you expose: the registry has no extra work to do, the registrar has no extra work to do to understand messages in unknown namespaces, registrar is not blocked at all for any new namespace introduced, the registrar has no problem if the registry message does not validate per its own XML schema, the registrar does not have to be proactive it can deal with new cases and problems later, etc. I really fail to see the drawbacks but of course anyone is free to do differently and stick to validate and parse everything in band in real time. As for "A client would need to proactively deal with the unexpected if the server does not honor the login services of the client.", I think this is already the case for many registries, and since a long time, so clients had to deal with that already. It is far from a new hypothetical problem. > Since this is not a problem unique to draft-ietf-regext-change-poll, I > agree that it's best suited to be addressed in a separate Internet Draft > that addresses service-aware EPP poll messaging. I agree this should be a separate draft, to become eventually an Informational Standard or a Best Practice depending on its content. > Is there interest in such a draft by the working group? I am interested by the subject but disagree on the offered solution. Also, it may be useful to be able (as difficult as it may be) to understand a little more on the current situation, and to see how registries currently handle this problem. Note that this happens very early and not only from poll messages. If the registrar logs in without the secDNS extension, to use a "core" example, and if it does a domain:info on a domain name which has secDNS info (because it is one of his own domain for which he put DNSSEC material with it before but right now in this particular session it did not use the secDNS extension at login, or maybe less contrived before a transfer he does a domain:info with the associated authInfo on a domain name it does not sponsor) then what should the registry do? Send the secDNS part of the domain:info or not? 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. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Regain of interest in RDAP tiered access?
Hello, As you may be aware, ICANN discussed with WP29 on issues related to GDPR and whois. Among the set of documents exchanged there is this timeline: https://www.icann.org/en/system/files/files/gdpr-timeline-implement-action-plan-20apr18-en.pdf Besides the time frame goals exposed that I let you judge by yourself (it remains to be seen how European regulators will allow exceptions on their dates published 2 years ago), I see specific mention of layered access for RDAP, which is refreshing after so many years of blind views on this by governing parties. This also may mean more (expedited?) work to conduct in this working group to deliver solutions for proper RDAP layered access :-) And Scott's drafts and experiments are probably very good starting points. Let the festivities begin! -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Host update and removing V6 glues aka comparison normalized and compressed representation
On Thu, Apr 26, 2018, at 13:21, InterNetX - Marco Schrieck wrote: > we found out that different registries have a strange behave while > removing v6 addresses. [..] > What should be the correct behave in such situations ? RFC 5952 A Recommendation for IPv6 Address Text Representation August 2010, Standards Track Selected quotes: It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. 3.2.1. General Summary With all the possible methods of text representation, each application must include a module, object, link, etc. to a function that will parse IPv6 addresses in a manner such that no matter how it is represented, they will mean the same address. The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. It seems to me that the system (EPP server) should accept the IPv6 in any legit format and map it to its internal format whatever it chooses to use, before applying any other kind of business rule, such as accepting or refusing the command. > IP addresses are anonymized. Next time, for obfuscation, use guidance from RFC 3849. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Fwd: New Version Notification for draft-brown-whoami-00.txt
On Thu, Jan 25, 2018, at 17:30, Gavin Brown wrote: > WHOAMI is not a complete replacement for WHOIS; You introduced the document by saying: "So I wrote this Internet-Draft which describes a simple decentralised alternative to Whois/RDAP directories. " Hence my confusion about what it should do or not, and hence its possible limitations. I believe that you will need to clearly specify the intent and the goal you want to reach with this, before the document could be reviewed and go forward. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Fri, May 11, 2018, at 15:32, James Galvin wrote: > With that, version 06 of this document has been published and the chairs > are declaring WGLC closed. The document is now ready for submission to > IESG for consideration as a Proposed Standard. Isn't that a little rushed? >From a quick search I have found about only 2 explicit mention of support of >this document, from Pieter and Scott (as for myself I can not say I >explicitely support it because I am still uneasy by the need for it or not >seeing it and still not understanding some part of it like all the "role" >part). Also the document went into so many iterations during the period that it was basicaly impossible to follow (one night I have tried reviewing its newest version by implementing it in my client... to find out in the morning that a new version went out so I kind of decided to stop giving it my time before it stabilizes in some way); some new comments even just popped out on the mailing-list yesterday. So I feel uneasy process-wise. Based on the amount of iterations during WGLC it looks like to me that there is at least still some work needed on it, and I am not sure its current version correspond really to the working group consensus. The above applies the same way for the two "organization" documents. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] IETF 101 minutes, and discussions not happening on this mailing-list
Hello, I do not seem to have seen the minutes posted on this mailing-list unfortunately, or I failed to spot them by looking at email subjects, sorry in advance. Anyway there is two points that I find troublesome in: https://datatracker.ietf.org/doc/minutes-101-regext/ > Registry Mapping, Roger Carney > Open question on boot strap for registry mapping > Discussion about how to distribute the data and if it is public at all. > Question if this data should be in EPP, RDAP or something else. > Next step: make a draft, adaption Why is this not done and discussed on this mailing-list but only during face to face meetings and over the phone? I think this excludes some participants and also lacks any kind of material minutes and searching capabilities. > James Galvin mentions that ICANN has a tech ops groups with many > registrars present. This group will send documents for > standardization to the Regext WG. Intense discussion about process > and involvement. To get standards people need to participate. I find that way to work quite worrisome. I do not think this working group should be rubber stamping documents elaborated elsewhere, even under the best assumptions for everyone, and even if "everywhere" is also populated by many people hanging here. It may be sad that not too many or not enough registrars are on this mailing-list, but instead of having the discussions elsewhere, why not encouraging them to come here? Each registry should do that for its registrars. If I take the latest (only?) example of this, it is the draft about registry message on maintenance. There was almost no discussion of it here, I was the only one to convey some comments/questions that were not acknowledged nor adressed in any way. It would find it very strange to see it come back and asking for the working group adoption. I have other thoughts about this working group, prompted by what we have seen recently on the TLS and DNSOP working groups so I will try to draft an email about that soon to see what the working group thinks, and hoping to improve the end results of our work. -- Patrick Mevzek ___ 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)
On Fri, May 4, 2018, at 16:15, Gould, James wrote: > My recommendation is to move forward with draft-ietf-regext-change-poll > and to leave the EPP server sending unsupported responses (mapping > extension and / or command response extensions) to a client based on the > login services up to a separate draft. I completely agree with this split. The problem that was discussed after this draft has in fact nothing to do in its core with poll messages, the issue, if there is one, is more global than that. I will try to expose it in another email. -- Patrick Mevzek ___ 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)
On Tue, May 8, 2018, at 16:21, Pieter Vandepitte wrote: > There's no such thing as a client which all > of a sudden must support or handle new extensions. Probably because the intersection of "clients validating absolutely all EPP frames received by registry" and "clients using blindly all extensions as announced by registry on greeting" is nil. However you may not have seen this case or not have been in one, but, for having been in one, I know it exists case where the registry says: at day X you can not connect anymore to the EPP server if you do not use on login namespace X and are prepared to receive messages with it. Then you are just resolving the problem we discuss by moving it into business-land: saying to the registrars to upgrade and thinking that you then can send messages with the new extensions because you are sure they will be able to handle it because they selected it on login... Maybe they instead just did a quick change to alter the login (specially if it the case of just one extension going from version A to B) and did not bother implementing things further than that > The client says it > does not understand it, That is not exactly the meaning I read from the login part. I am more reading it "I will not deal with this extension, I will not use it in my messages". See my following messages for an example. > 2. The purpose of the server's greeting service and the client's login > services: > > It's not a negotiate. It's informational, and in case of the login svcs > it's a kind request to only "talk the languages" of the supported > extensions. Should a server return an error when it receives a request > containing extensions it does understand, but which are not mentioned by > the client? No, even not for extensions it does not understand. We are now talking about the opposite case (what messages from the client should the server accept) and here I disagree with you: the client clearly designates at login which namespaces it want to handle, so the server should never accept messages with other namespaces from the client. This is also being conservative and helps defeat errors in the client. I know at least one registry server behaving exactly like that. > 3. Validating clients: clients should be permissive in what they accept. > A client must interpret the server's response as good as possible (i.e. > ignoring XSD violations, use of non-supported schema's, ...). > > What about poll responses potentially containing extensions not > supported by the client? Because of (3) that should not be a problem, > but since in my opinion a server should be conservative (to be able to > serve both validating and non-validating clients), it should send the > response in another way. This opens a new complete can of worms. Some registries send then emails, others give messages by HTTPS connections, etc. Many things outside of EPP since I believe that based on the constraints you pose there is noway to resolve that inside EPP. And BTW being liberal here does not impact negatively validating clients: when seeing a namespace, they can validate it conforms to a schema even if they do not really care of its content and do not use it. > This is in my opinion a task for the working > group. (Top of mind suggestion: encode part of the response which is not > understood as a CDATA block) I am in general completely against the idea of encapsulating one formatting inside another, as the idea was already suggested (changing the pure textual message by adding some formatting in it). Hence I would really not think that using a CDATA block is a good idea. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting
On Fri, May 4, 2018, at 18:33, Roger D Carney wrote: > 2. Registry Mapping > * Continue the lively discussion that was started in London Why is there absolutely no "lively" discussion of this also on this mailing-list? (since this lively discussion in London is also not documented very much anywhere as far as I can see). > Please reply to the list or directly to myself if you plan on attending > this meeting. I see no specific reason (maybe there is one, but it is not presented) why this work can not be conducted by email, hence I do not see the need of such a meeting right now. I would tend to ask why is this being done, even more so when it is not done/initiated by the chairs of the working group. https://ietf.org/blog/guidance-face-face-and-virtual-interim-meetings/ has the following points: * The meetings are scheduled by the working group chairs, who should discuss their plans with the responsible AD(s). * Minutes, including a list of attendees, must be sent to the working group mailing list within 10 days of the event * It should also be noted that as RFC 2418 section 3.2 points out, decisions at meetings (normal, interim. conference call, or jabber session) are not final and must be reviewed on the mailing list. Special care needs to be taken with this for topics or issues which have not been discussed on the mailing list or for outcomes that are significantly different from previously arrived mailing list consensus. And I note this from the notes of the interim meeting in January: "Next steps, Jim Gould will get internal approval to move forward and we will submit the draft and post an introduction to the list." Was the draft posted and an introduction to the list? If not, why another meeting before doing this step? See also my email just before about the IETF 101 minutes for the same problem. -- Patrick Mevzek ___ 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)
tion 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
Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
On Mon, May 21, 2018, at 16:15, Gould, James wrote: > The EPP greeting per RFC 5730 "identifies the services supported by the > server". The EPP login command services per RFC 5730 includes " > elements that contain URIs representing the objects to be managed during > the session" and "MAY contain one or more elements that > identify objects extensions to be used during the session". I don't > view the services included in the greeting or the login command as > information, but used to negotiate the object and extension services to > be used by the client and server during the session. The client must > not pass services that the server does not support based on the EPP > greeting services, and the server must not pass services that the client > does not support based on the login command services. James, Just repeating the same interpretation of some text in order to come to the same conclusion as the preferred one without wanting to see other points in the global picture is a sure way to close the discussion, and not to open it. > A client that is capable > of accepting every possible services in the response can simply mirror > the greeting services in the login services. Read my messages. You have examples when this does not correspond to reality. It is fine having only one implementation in mind and defining stuff to conform to it but, sorry, there are others, and other use cases too. > If we come to agreement on the meaning of the > greeting and login services then we can move onto the question of > handling poll messages that contain services that may not be supported > by a client. I think you are putting the cart before the horse. Like I said multiple times the problem, if it exists (as I am not sure it exists), must first be clearly specified, taking into account all use cases. Only after that we can discuss on how to read the current documentation and see what the conclusions are. Starting by interpreting the text to come to a favorable conclusion is not really trying to discuss or come into agreement or consensus in my mind. But again, I think we rehashed this point often enough now, so besides some specific document to discuss, or other new views to exchange, it may be better to let the thread die. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Interest in collaborating on an EPP over HTTP draft?
Hi Anthony, On Tue, May 22, 2018, at 18:09, Anthony Eden wrote: > I've thrown together a repo over at GitHub to work on an EPP over HTTP > draft (https://github.com/aeden/epp-over-http). I'd love to know if there > are others from the community who are interested on collaborating. As I am sure you are aware, some registries currently uses HTTPS, like .IT and .PL at least. It may be a good idea, if not already, to try sharing discussions with them and see if you can converge on something, if you are planning to do a standard. You may also be aware that when EPP itself was drafted they were then multiple other proposals for transport, besides TLS. There was at least SMTP if I recall correctly and BXXP (BEEP) which I think does not really exist anymore but it looks like to me that many of its features are also present nowadays in HTTP/2. Maybe there are some ideas to grab from these past attempts, the documents themselves or the discussions. > As a > registrar, we'd love to be able to work with registries using HTTP as the > transport protocol in the future. I am curious, why particularly prefering HTTP over TCP (or more precisely HTTPS over TLS)? Did you tak time already to document the differences with TCP, in the realm of EPP, what are the benefits and the drawbacks? > Note that the current version of this draft deals solely with EPP over HTTP > 1.1, it does not consider HTTP 2 at this time. (I did not look at your code/document yet). Why is it so? Just a lack of time or some specific reason against HTTP/2? If there anything that works with HTTP/1.1 but not /2 it should be documented. As nowadays, for new works, I think it is best to concentrate on the newer versions of other standards when you do a layering (hence HTTP/2) instead of forcing retro-compatibilies, except if good reasons for that of course, this is what I am curious about. -- Patrick Mevzek ___ 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)
On Tue, May 22, 2018, at 14:23, Gould, James wrote: > Referring to the language in the RFC is the starting point in the > discussion related to defining the problem that may or may not require a > solution. If everything is already crystal clear from the existing documents I do not know why you even presented 4 different options at the beginning of the thread. So if everything is clear, there are no options, and no problem to solve either. I can hence leave this conversation where it is. > I disagree that we should look at the various implementation > policies implemented in the wild by registries and registrars to develop > the appropriate interpretation of the RFC. Which is absolutely not what I said. So I will stop here, as I may be doing more harm than benefits to the WG by continuing. Regards, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Interest in collaborating on an EPP over HTTP draft?
not a very light serialization mechanism. > I have nothing against an HTTP/2 implementation, I just don't see it as > having the same benefits as HTTP/1.1 given that HTTP/2 uses a single TCP > connection and multiplexing, effectively negating the stateless benefits of > HTTP/1.1. Ok, I can see that. But I think it would still be strange to define a new standard today saying that you need to use HTTP/1 with it and not the newer HTTP/2. And at least in the gTLD world, things could probably not implemented before existing as an RFC. And some gTLDs are very small. This is not technical related but may need to be taken into account if you wish for large adoption. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Wed, May 23, 2018, at 14:05, Gould, James wrote: > I would like to understand the concern around the use of the roles. > There are cases where an organization can play multiple roles > (registrar, privacy proxy, dns provider, etc.) that helps defined what > kind of links can be made to it. Just an example (I do not wish really to revive the discussion) among others: Imagine a registrar A for registry B, typically a ccTLD. Registrar A creates an organization O in this registry B It happens that O is a dns provider, let us say. So it is created with this role. Later O becomes ICANN accredited, for example. This is another role. What totally escapes me: why shoud this be reflected in any way, through registrar A in registry B because O is provisioned there? In short my main problem, and why I can not support this, is that I do not see the use case, besides for one registry that needs it to handle resellers, I doubt having seen another registry saying it will use it, so we are just paving the way to enable storing more data, where the world goes instead towards storing less or more carefully (see the current dramas around GDPR) Not everythint that can be done should be done. This is the main point I will try to address in a separate email since it is a generic issue, not specifically related to this proposal. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote: > @Patrick, did you have time in mean time to catch up? How would you like > the draft to be changed in order to support it? I unfortunately think that I am not convinced by the use case, and I believe that the document could be an I-D referenced on the IANA EPP Extensions registry without the need to become an RFC. Which other registry wish to use it on their systems? And if there is, then for other things than resellers? That does not change anything on the WG consensus on the documents, which should proceed on their own pace. > I guess it's the fact > that roles are defined as properties of the organization and at the same > time as properties of the link? Yes, that is one troublesome point I raised months ago. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Thu, May 24, 2018, at 12:37, Pieter Vandepitte wrote: > The only thing that bothers me in general (not only for this extension) > is the low participation in discussion making it difficult to develop a > specification that fits all needs. I think there was quite a lot of participation at the beginning, hence the change from reseller-centric to more generic. After that, my gut feeling is that no other registry needs it right now. Maybe in the future, and like you say they are waiting for it to be an RFC. > I do not agree with you regarding not moving forward. I did not say not to go forward, sorry if I miscommunicated. On the contrary, the consensus is clear, even if the participation is not overwhelming. Go forward :-) > It is certainly not my intention to try to convince you to approve the > draft. I will continue my write-up but I will write down your concerns > and it's up to others to decide whether the Draft can become a Proposed > Standard It is past LC like the chairs said, so the ship has sailed. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Object template extension
Pieter, On Fri, May 25, 2018, at 21:37, Pieter Vandepitte wrote: > The registry I work for, developed a custom extension to manage > "nameserver" groups and "keygroups". When a registrar links a group to a > domain, all member nameservers/keys of that group are automatically > linked to that domain. This way, it is very convenient for DNS operators > to update DNS data on their complete domain portfolio with a single > group update, without forgetting a domain. > > It is used quite a lot, but I did not find other registries having this > kind of functionality (I did not perform an extensive search). I'm quite > sure we are not the only ones, so do you know other registries having > this? I know two extensions: - the .BE/.EU one: the last time I have looked at them, it was the same, except for the namespace - the .CZ one, in fact in their Fred open source EPP server (so probably used for their others TLDs), see https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Nssets.html and https://fred.nic.cz/documentation/html/EPPReference/ManagedObjects/Keysets.html >From memory, they cater for the same needs, but are basically incompatible, >besides the namespace. Starting with the terminology: "group" on one side, "set" on the other. I would add 2 remarks: - for nameservers it seems to me to make more sense when hosts are objects, instead of attributes while obviously it works in both case. The world is quite divided on this, gTLDs are mostly (only?) in the objects group, while ccTLDs are predominantly in the attributes group - for DNSSEC material, here we hit another problem, the DS vs DNSKEY dichotomy, partially reflected in the dsData vs keyData interfaces of secDNS-1.1 All grouping cases only make sense of course with the DNSKEY case, because the DS depends on the domain. Again, without any hard facts, I still believe that most registries are using the DS case. Some, even with the dsData interface, ask also for the underlying keyData, but only to check that the DS was correctly computed. Also, such kind of features have consequences for transfers. > Is there any interest from the community to offer such a feature to > their registrars and collaborate on a common extension? I think of > something more generic in a way that a registrar can create a "template" > for any kind of object and apply that template to other objects. This > way, besides the benefits for DNS operators, a registrar could also > define e.g. a default admin contact for every domain, or even apply > custom extensions to every domain… Note that there were various attempts to define features such as templates, containers, or bulk operations. Specifically for bulk operations, since the discussions often circled around that the primary argument was that EPP is a provisioning protocol and as such is not tailored for bulk operations. Which brings immediately this counter argument: ... but you can query for more than one object in a given command. Note that while not completely the same, issues of "bundling" domain names due to IDN variants typically is also loosely related to all of this. One of the latest iteration around these concepts was this draft: https://tools.ietf.org/html/draft-gould-regext-dataset-01 HTH, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Fri, May 25, 2018, at 15:45, Antoin Verschuren wrote: > 1. I saw the need for some registries to give organizations other than > the traditional Registrars and Registrants a role in the registration > process, but this was not limited to resellers. But yet I am not sure to have seen a lot of registries here saying that they need this extension, or that they plan to use it... > The discussion started because resellers were complaining that their > name didn’t show up in the whois for specific registrations, and > Registrars were complaining that Registrants of those registrations > would call them in stead of their reseller. Registrants simply forgot > who they had signed a contract with, so they looked it up in whois. > Registrars wanted to list their reseller in whois. Registrars can today publish reseller data in whois. This does not need to be sent to the registry, nor to have a specific EPP extension. This is covered I think in ICANN world by section 1.4.2 of the whois specification: "Additional data elements can be added at the end of the text format outlined below." So registries/registrars could be free to add reseller data today, even without any change to EPP. And in other worlds, where there is not necessarily a registrar whois, it all depends on the registry policy to see what will in whois, and no technical change could change this policy, so again I do not see how the EPP extension helps here. > Appart from resellers, I could see other roles in the future. Working on > Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would > be another organization registries might want to give special rights to, > for example to change NS records or roll DNSKEY material for domains > they were responsible for. This is all true, probably, but how does it goes from there to "these operators need to exist as object in the registry database and be made under control of the registrars"? This sidestep many other points, like, one dns-operator for example, could be operator for domain names sponsored by registrar A and registrar B. Will both registrar A and B need to create an organization object for this same and only dns-operator organization? What exactly does this benefit to? In a GDPR world you need more and more to be very specific about the data you collect, its use, and how you keep it. While it does not apply exactly as is here, I still fail to see why the registry database need to be populated with all this data. And while I can understand James argument and design I think we are making things over complex without direct benefit, for what I understood the only use case applicable on the table is "storing reseller data in registry database (and maybe showing it in whois)". For such a simple need, I think we are over-designing stuff. Of course things would change a lot if many registries would come showing their support for this extension as it would help them for their various business needs. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
so if using VPN what about the > > needed features > > of authentication? You do not say. > > > > In short, remove "or VPN" and all problems are solved. > > > > The requirement is about authentication, not encryption. Exactly, which is why, even with a VPN you would still need TLS for end to end authentication. So it can not be "VPN or TLS". The VPN may secure a part of the path but not all of it, while TLS can be end to end for both confidentiality and authentication needs. Except of course if your use of VPN would be to say that the registry provides a VPN endpoint for registrars to connect to it... > > * 4.2.1.1.1 > > I believe a PUT would be more REST-like in this case > > (kind of "creating" DS data at the registry for the object being the > > domain) > > than a generic POST (see my discussion previously) > > > > POST was chosen there to differentiate it from the PUT request at 4.2.1.3. I think that HTTP verbs should not be chosen on the basis of "differentiation" between one part and another of the protocol. They should be chosen on the sole merit of what action they encode. If you create a resource, it should be a PUT. POST is more an all-purpose default if nothing more specific matches (and to be nice with poor client implementations that know only about GET and POST but I am never happy to standardize on the lowest common denominator). > If I recall correctly, I think we chose to do it that way because we felt > POST made more sense for new data, while the PUT made sense as a > modification to existing data. While we are entering REST-bikeshedding area, for me it is more PUT to create data and PATCH to update it, or POST as a last-resource. But again, and more to the point, I do not think your protocol needs the REST framework. > > * 4.2.1.2 > > Is there a specific reason to separate the case of removing all DS records > > from the case of generic DS records update detailed after? > > > > Yes. Removal of all DS records is a security downgrade, while removal of > some DS records in the course of updating the DS set is not. The two > operations have distinct signals in CDS as well. Ok I say, but then removal of "some" records could be all records in fact, so end operation is the same. > > * 4.3. Customized Error Messages > > > > This is clearly underspecified. How it is formatted in the body of the > > response? > > Especially since you later say that it is a protocol for machine to machine > > communications, so these communications must be framed inside > > specific structures. > > > > I believe that since that is the only thing that may be in the body, it was > assumed it would be a simple text string. No extended error message is > ever going to be used directly by a machine.. it would have to be stored > and made available to a human looking into the results of a request.. so I > don't think further structure is necessary. However, we should have > specified this more clearly. I don't think it's a bad idea to give it some > sort of structure, especially to allow for the separation of an extended > error code and extended error text. > > If we did add structure to the body, my personal preference is for > something light-weight and human debuggable like YAML or JSON. Does anyone > have strong feelings about that, or other formats we should consider? If you want to be really REST-conformant in spirit, the response format (text, XML, JSON, YAML, etc.) should be under control of the client, with the Accept headers. Probably one additional reason why I am saying that, for your simple needs of a signalling protocol, the REST-framework is too much, if followed. > If we really wanted to be simple about it, > the entire thing could be a single GET URI, or even a custom ICMP message, > but we felt that as long as we're specifying this we might as well enable > it to carry more detail than that. I think this kind of explain many problems: it is not enough of a simple signaling protocol, but too much of something more complicated with authentication built in. I would think this is the core point to address: if DNSSEC related authentication is enough, then make it really just a signaling protocol. > Even though further authentication of this protocol isn't *technically* > required, we realize that there may be business requirements that would > lead a Registrar or Registry to want to limit who can access the servers > where they provide this service, especially if they've chosen to enable the > bootstrapping of trust, and there are several places in the document where > we have a nod to these business requirements. We feel that mentioning that > operators may want to implement such limitations is sufficient, and it's > not our place to specify what they SHOULD be, since it's not technically > required by the protocol. I would say have a look at the RFC about EPP over TLS, it has sections about what kind of limitations should be put in place. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
On Tue, Apr 24, 2018, at 21:02, Matthew Pounsett wrote: > On 7 January 2018 at 18:28, Patrick Mevzek wrote: > > > > > > > On Fri, Dec 22, 2017, at 07:03, Patrick Mevzek wrote: > > > Hello authors, > > > > > > Please find below my review of your draft. > > > > Please also have a look at > > https://tools.ietf.org/id/draft-hildebrand-deth-00.txt > > as it covers related goals (it is more generic than just NS/DS needs) > > > > I do not know where it is discussed nor its current status. > > > > It may however be of interest to this WG. > > > > I've seen that draft before. It's a sort of "DNS UPDATE over HTTPS" > system. While there may be some overlap in what it provides, it doesn't > have the same goals or applicability of our draft. We're trying to write > something that can be inserted into the existing ecosystem with limited > overhead. Something like draft-hildebrand-deth requires authentication, > whereas this scheme doesn't. > > We've also received a fair bit of push-back to any suggestion that we might > expand this protocol to allow updates of NS records. I still think that at soon as you have a mechanism to be able to change something, like DNSSEC related materials in your case, people will ask to be able to change other things. This does not mean that all should be covered by a single mechanism but you may always find other ideas in other proposals that could help or not, and at least include some working in your own specification to clearly say: this is suitable to do X, but could be extended to do Z but probably not to do W. BTW, see how they use the "_deth" label in the DNS to identify the endpoint, as suggested in your case to defend against any hardcoding and having to name precisely the endpoint for everyone, as anyone knows that the naming is the hardest part of computer science. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
Matthew, On Tue, Apr 24, 2018, at 21:02, Matthew Pounsett wrote: > We've also received a fair bit of push-back to any suggestion that we might > expand this protocol to allow updates of NS records. I just found out (again) about the CSYNC record. See RFC 7477 Child-to-Parent Synchronization in DNS Abstract This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. It specifically excludes CDS/CDNSKEY handling of course (section 5) but it is a generic signalling protocol. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote: > Op 27 mei 2018, om 21:23 heeft Patrick Mevzek het > volgende geschreven: > > > This is covered I think in ICANN world by section 1.4.2 of the whois > > specification: > > > > "Additional data elements can be added at the end of the text format > > outlined below.” > > Ah yes, let’s take the solution of "we can put everything in one non- > parseble TXT record like DNS can do too if we fail proper design and > really want to” ;-) > Sorry for the sarcasm Patrick, but that one was a too open goal ;-) I am not sure to see where in the text it says that formatted content is forbidden, can you pinpoint it to me? Also, I fail to see how any EPP extension would have any impact here (in the sense that: you can change what is displayed in whois irrespective to what happens on the EPP channel). > > In a GDPR world you need more and more to be very specific about the data > > you collect, its use, and how you keep it. While it does not apply exactly > > as is here, I still fail to see why the registry database need to be > > populated with all this data. > > You forget to see that this will benefit registries that want to do the > right thing where they are now limited by protocol. I asked many times who these registries are, I still fail to see broad consensus by registries to implement these extensions (I do not count silence as being "I agree" but just as "I do not care" or "I am not following these discussions, I do not know what to think about it"). Maybe they are thousands of them just anxiously waiting for this work to become an RFC (like it never happened in the past with registries implementing even core EPP documents before they became RFCs...), or maybe there are just not many of them needing all this... Noone knows but I have my ideas in which case we are. > It allows innovation. Innovations do not need RFCs, that can happen before. This would be a separate topic. > I’ve seen registries that want to add reseller data in > whois/RDAP at their registrar’s request, registries that want dns- > operators to be able to roll their registrant’s DNSSEC keys, they want > to be transparent as tho which organization has extended RDAP access, > etc. And the registrars are still in control over who they trust with > these limited registry credentials, but in the end they will save costly > customer support and have more extended service if they automate. Maybe. At least this is not shown by discussions here, which is sad. Also, I am still not sure the proposed extensions solve all of these problems anyway. Especially if you take into account the drawbacks as any solution has both benefits and drawbacks, nothing is a pure win. > We took the challenge of doing more work now, to have quicker innovation > later. And I see more use cases than just the reseller one. Maybe. I am not convinced by the data proposed on the table. There may be a lot more elsewhere, but here I do not see. Anyway, this is moot. The extensions will go forward and become an RFC and then we will be able to jauge really the interest by registries and how it is implemented... -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC: draft-ietf-regext-org-02
Antoin, On Mon, May 28, 2018, at 22:40, Patrick Mevzek wrote: > > > On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote: > > Op 27 mei 2018, om 21:23 heeft Patrick Mevzek het > > volgende geschreven: > > > > > This is covered I think in ICANN world by section 1.4.2 of the whois > > > specification: > > > > > > "Additional data elements can be added at the end of the text format > > > outlined below.” > > > > Ah yes, let’s take the solution of "we can put everything in one non- > > parseble TXT record like DNS can do too if we fail proper design and > > really want to” ;-) > > Sorry for the sarcasm Patrick, but that one was a too open goal ;-) > > I am not sure to see where in the text it says that formatted content is > forbidden, can you pinpoint it to me? > > Also, I fail to see how any EPP extension would have any impact here > (in the sense that: you can change what is displayed in whois > irrespective to what happens on the EPP channel). In your quote you missed the other part which is basically: all domain names are not under ICANN policies. 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? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
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
