[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] 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] 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
[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
Re: [regext] Contact Postal Info Elements Proposal
Gould, James <jgo...@verisign.com> 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 <jgo...@verisign.com> 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] 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
> 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
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] Request for Working Group Last Call for draft-ietf-regext-allocation-token
t 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] 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] 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] Interest in collaborating on an EPP over HTTP draft?
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 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 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] 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] 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
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] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote: > [SAH] Jim, keep in mind that the security guidelines you mentioned are > just that – *guidelines* published by a particular entity that may or > may not be appropriate for use in different operating environments. I’d > be inclined to loosen the Schema to conform to other possibilities and > include an informational reference with text along the lines of “Servers > SHOULD enforce minimum and maximum password length requirements that are > appropriate for their operating environment. One example of a guideline > for password length policies can be found in [reference > here]”. A minimum length of 1 would ensure that the field can’t be > blank, and the server can check if whatever is provided lines up with > expectations for clients. That sound perfect to me. Thanks Scott for the text. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Mon, Jun 11, 2018, at 19:43, Gould, James wrote: > In thinking about decreasing the minimum from 8 to 1, I have a concern > that we're going to support a minimum that is below the existing RFC > 5730 of 6 characters. I believe it would be best for the Login Security > Extension to at least support the existing 6 character minimum with the > added language that Scott proposed “Servers SHOULD enforce minimum and > maximum password length requirements that are appropriate for their > operating environment. One example of a guideline for password length > policies can be found in [reference here]". Scott's > language can be added to the Security Considerations section of the > draft. > > Let me know if this will work. I do not oppose that if this is the consensus but I still see it as pointless to provide *any* specific minimum limit here, and I do not see the problem with going lower than RFC5730 since this extension is optional and, hopefully, if it is used it means the relevant registry has decided to put more energy and work around security measures so you could hope they would deal with this minimum issue gracefully (that is enforcing something higher than 6, and not lower, if they do define the space of characters allowed too). -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Mon, Jun 11, 2018, at 21:57, Gould, James wrote: > Patrick, > > > > > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 > > > and 8265. > > > > Please also look at the SASL framework (RFC4422 and RFC4616 for its > PLAIN version which is basically what we have currently) : this allows > to decouple authentication needs to the underlying application/protocol, > which also address Pieter remark about other ways to authenticate. > > > > JG - I don’t believe there is any desire to switch from using the > variant of the PLAIN SASL mechanism [RFC4616] defined in the existing > EPP RFC [RFC5730]. I do not know. My main point was more around: if we decide to put more energy into "securing" EPP better, providing more options than just plain text passwords (as asked by Pieter also I think) would be now a good time to think about, and if we go towards some "extensibility" in authentication frameworks, why not just build on existing RFCs? -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Proposed Revision to our Charter
On Fri, Jun 8, 2018, at 15:51, James Galvin wrote: > As we have discussed in at least the last two IETF meetings, we would > like to propose broadening the responsibility of this working group to > cover the standards related generally to Internet Identifier systems. I am sorry not to have been able to participate in the last two meetings, but I also find no discussion on the mailing-list about this, so can you provide more context? Specifically because regarding the minutes of IETF 101 and 100 I see nothing about this in 101 and in 100 only: "Discussion about broadening the charter to adopt other "registration-related" documents, once the document "plate" is clean. Before london, several documents should be off our WG, and we can adopt more documents." from one individual. I feel missing quite a lot of pieces of the puzzle. New work may be interesting, but one has to question first if this is really related to what we are already doing (what is the overlap?) and then if the group has enough resources to tackle more work when: - we are late in our milestones, and not by little (almost one year for the fee extension, more than 6 months for the organization one, etc.0 - it is difficult to find shepherds for write-ups (I can testify :-)) - there are not so many individuals commenting/reviewing each draft on the list, so consensus is already quite hard to achieve. > Attached you will find a proposed revision to our charter that would > allow this. > > Please review and provide any comments or concerns to the mailing list. My concern is that there is only a short sentence added to the current charter that does not give a lot of details about what we are speaking about here, especially since EPP and RDAP are detailed before in many sentences. So, in short, I am uneasy to say anything because I lack both context and substance about what we are talking about. Some examples of relevant work could also be useful. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting
On Wed, Jun 6, 2018, at 14:21, Gould, James wrote: > This dependency > does require ensuring that the host XML schema is loaded ahead of the > domain XML schema when pre-caching the XML schemas. So it seems having dependencies is only a problem or a difficulty when validating the frames per the schemas. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Wed, Jun 6, 2018, at 15:02, Gould, James wrote: > JG - I don't view the 8 minimum as a "sacred cow" that would require the > next iteration of the extension to increase it. It was 6 before and apparently we "need" to upgrade to 8 now. I am quite sure than in 5 years we would want to increase 8 to 10 and so on, this is purely Moore's law. So to ease future maintenance I am just saying: remove this arbitrary limit in the protocol, since it is a policy decision anyway. > but I don't believe that it makes sense to not > at least define the minimum to meet the existing security guidelines. For me defining a minimum has no sense if you do not define the space of possible passwords (which characers) and even various other constraints you may place (like no repeating character, or at least one uppercase, etc.) For the sake of it, imagine the space of allowed characters are digits. Do you think the security would be increased in any way going from a length of 6 to a length of 8 digits? > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 > and 8265. Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN version which is basically what we have currently) : this allows to decouple authentication needs to the underlying application/protocol, which also address Pieter remark about other ways to authenticate. This would of course imply bigger changes and deeper ones, but for extended features also. I note in passing that there was always a way to extend authorization mechanisms in EPP, for the domain:auth element. I have never seen however any extension proposing there anything different. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt
could be done "easily" if you take my ideas on top to have blocks identified by the underlying XML namespace or RFC number): - data related to transport: number of connections, timeouts (soft and hard), recommended frequency of keepalive, etc. - data related to sessions: password policies (maybe both for registrar login and for domain authInfo) which go further than just regex you may want to code about lifetime of a password, and the sets/classes of characters allowed and their use (like mandatory one uppercase character, one lowercase, one "special", etc.), etc. For domain passwords, is allowed? (an arcane part of the standard that I know one registry does) Also/maybe: - various rate limiting (per command or not, etc.) - various hitpoints mechanism (ex: 1 hitpoint per EPP error, cut of all write operations after X hitpoints, for X days or token bucket like operations) - data about notification messages: how long are they kept in the queue? What happens at end of lifetime? - "extended" error codes used Finally, as bikeshedding as it may seem, I am not convinced that "Registry Mapping" is the correct naming here. The abstract talks about zones, features and policies. All other EPP standards talks about server and client, not about registry and registrar. I would favor changing the name of the extension and removing Registry from it. I lack good suggestions for now, maybe later. Policy Mapping? Metadata? Zone Metadata? -- 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] WGLC: draft-ietf-regext-org-02
On Wed, May 30, 2018, at 22:24, Antoin Verschuren wrote: > I remember a CENTR meeting where ccTLD’s tried to get consensus over if > we could harmonize EPP extensions so registrars would not have to code > differently for every TLD. > This was before EPPEXT existed. > We all thought this would be a good idea. > But half the registries concluded that they wanted to stick to their own > extensions because they felt local legislation or their local > constituencies required them so, and the other half had the standpoint > that they would only implement as followers, after extensions would be > standardized. I have thought for a long time about EPP standardization and I came into conclusion that if consolidation does not happen it is for reasons outside of the technical realm. Hence my belief no technical solutions would change any of it. > This was not only TLD registries that had an opinion, > and I remember some hesitation especially by ICANN registrars as well > because they didn't want extra work, but third party dns-operators, > ICANN related policy makers, RIR’s, registrants and plain IETF protocol > guardians also have an equal voice in the IETF process, even though they > don’t implement. While every voice is welcome at the table, I still like and favor the idea of "running code". Besides rough consensus which you are all saying we have, so let us go forward on this topic and standardize this extension that so many actors want or agree to. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote: > I follow the concerns of Patrick, > > I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify > that a server MUST ignore the value of if the loginSec extension is > used? That could be a solution too, and would work for further versions. > I don't know if I overlooked it, but it seems that there's only support > for password based login and provisioning. Do you plan to support other > things like digest authentication? I agree that it could be useful and I forgot about that, it could be a good idea to make something more generic at the same time, to handle other kind of authentications. There is already a VeriSign EPP extension for 2 factors auth, I do not find it online anymore but I implemented it and it was for namespaces: http://www.verisign.com/epp/authExt-1.0 'http://www.verisign.com/epp/authSession-1.0 but it was more for domain:update operations. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting
On Mon, Jun 4, 2018, at 19:56, Gould, James wrote: > 4. I don’t recommend directly referencing the > urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct > dependency to inclusion of the contact XML schema and namespace for a > subset of the elements that are really specific to the validate mapping. > I would prefer for the validate XML schema to stand on its own by only > referring to epp and eppcom, with no cross references to contact. This > would mean copying and pasting elements directly from the contact XML > schema into the validate XML schema, which is an inconvenient, but makes > it easier to implement. I am sure that not all elements of epp/eppcom namespaces are used either so under symmetry and consistency I would find more logical that all schemas are treated the same, either all referenced, or all copied (for the parts needed). And I see no problems in referencing the contact-1.0 one. Using epp/eppcom as references already make the schema dependent on other resources and not "standing on its own". I am not sure this has a huge consequence on implementations, especially if taking into account multiple ways to implement things (and especially doing validation or not). -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Tue, Jun 5, 2018, at 17:11, Gould, James wrote: > JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730 [..] Yes, but my comment was both to propose other values than this string and even alternate mechanisms. Please have a look and let me know. > There may be a better constant value to use or another > mechanism that is compliant with RFC 5730, while allowing for overriding > the password value in the extension. This is indeed the subject on the table. > - for loginSec:pw/loginSec:newPw I am not a fan of specifying > minimum length, because if you remove all maximum length constraint in > the schema for the maximum, by symmetry I would do the same for the > minimum, leaving both to pure policy choices by the server (the > "sensible" minimum depends of course on the number of different > characters allowed, it would not be the same value when accepting only > ASCII or when accepting "any" Unicode characters > > JG - I don't believe that the security would be enhanced by removing the > minimum length. RFC 5730 had a minimum of 6 characters and I bumped it > up to a minimum of 8 characters to match current password security > guidelines. NIST defines the minimum length as 8 characters. I never said the security would be "enhanced" I am saying that if part of the goal of the new extension is to remove previous artifical limits on length, it might as well let the policy decide what good vales are, instead of the protocol. Defining a minimum length without defining the space of characters allowed nor miscelleanous rules regarding complexity seems defeating the purpose, you just enshrine some arbitrary numbers as sacred cows. And the next iteration of the extension will again need to lift the value. > - I would also not put anything here related to what characters are > allowed or not. I would instead defer to the PRECIS framework (RFC7564) > and more specifically section 4 of RFC8265. At least as a base, using > OpaqueString and then building one more constrained on top of it if it > is really deemed important > (passwords here are typically not seen nor managed by humans, so I > think they need less strict rules than when handled by humans, and I see > no problems per se with spaces... I have seen far more trouble when > people try to use < or & in a password and forgetting to encode it as > those are specific characters in an XML streams). > > I know that RFC5730 does the same thing, but it was written before PRECIS. > So now I think we should instead build on it. > > JG - The rules around the leading / trailing whitespace and the > contiguous whitespace is based on the selection of the XML schema > "token" type. We could consider changing the type, but that is the type > defined in RFC 5730. The login security extension simply removes the > maximum length constraint and increases the minimum length constraint > from 6 characters to 8 characters to meet current security guidelines. Please have a look again at what I wrote and the details about PRECIS. I still think that this is not core EPP and hence we should defer to other RFCs dealing with passwords for recommendations instead of trying to invent new ones. This has nothing to do with the XML schema type. And I am still not convinced that whitespaces are a problem here (again, because the password is entered by a program and not by a human), but this is a bikeshedding point. -- 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 <p...@dotandco.com> 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] 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
[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] 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] 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] 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] 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
[regext] Review of draft-ietf-regext-dnsoperator-to-rrr-protocol-04
cords update 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
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] 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] 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] 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] [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"
y 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 systems too: do they have notifications? If so, where? (because registrars may not poll on OT systems so it may make sense to publish OT 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
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] 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] 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
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] Tidbits after monday meeting, related to registry mapping extension => Structure
On Tue, Jul 17, 2018, at 09:33, Patrick Mevzek wrote: > https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry I have hinted in the past that I believe another structure for the XML piece of data about zone policies could provide more benefits, such as: - by not having parts of the information inside an EPP extension under , but everything in the same document it means the document can be published as is; I think this can help resolve the bootstrap problem discussed during the meeting as the XML document, both its "core" part defined by this draft and all extensions inside of it defined by other drafts, could be published as is under whatever channel the registry decides, for example HTTPS, on a public or authenticated website depending on its own wishes. - by doing so you reduce the risk of having multiple registries implement the same extension to encore the same policy (ex: what are the extra attributes for a contact, if they are the same between the 2 registries) in different documents with different namespaces - you simplify the writing of extensions, there is much less boilerplate coming from just the fact that you need to reuse EPP extension framework. So here is my proposal, first the current (simplified) structure to have a base to compare to, and then my suggestion which can be refined in many ways, and specifically the naming of attributes. I believe that in such way the core document is not held up by any future extensions, as it just define how to add extensions, with an unlimited number of unorderer slots, one per policy group (each group tied to a specific XML namespace, hence a specific document) CURRENT DOCUMENT ... ... ... ... ... all policies related to domains, including RGP and DNSSEC ... all policies related to hosts ... all policies related to contacts ALTERNATIVE PROPOSAL ... ... ... all policies regarding session commands, login, poll, etc. previous registry:services and registries:svcExtension would be there ... all policies regarding domains ... all policies regarding hosts, absent if hosts are attributes ... all policies regarding contacts ... everything related to the transport, if needed (not sure about that, or if this can be in the first registry:policies block with RFC5730 data; I am not fond of the namming either in this case) ... all policies regarding DNSSEC, if supported by registry ... all policies regarding RGP, if supported by registry ... all policies regarding launchphase, instead of a separate launch-policy extension document http://someregistry.example/epp/localExtension;> ... all policies regarding this registry specific EPP extension -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt
On Mon, Jun 11, 2018, at 15:48, Gould, James wrote: > More specifically now, about "2.3. Schedule" I am *strongly* > against using the format proposed for at least 2 reasons: > - crontab format is not a standard, and is ambiguous for various > points > - it encodes a format as a string which is itself in a formatted > structure since it is XML. "Hijacking" some free form space when you are > in formatted structure seems wrong to me and shows that the structure is > not correctly formatted because if it were you would not have to inject > a new format in a free text. > > Why not use ISO8601 Repeated Time Interval format? We are then still > gulty of the previous point but at least it is a standard. > Otherwise please amend the XML structure to break the content > currently in the crontab format. Another way of encoding that, without judging myself if it is good/bad/better or worse than others but just to open horizons and see what is out there since I just stumbled upon it for unrelated reasons, is the systemd way, as described on https://www.freedesktop.org/software/systemd/man/systemd.time.html With this example: Thu,Fri 2012-*-1,5 11:12:13 The above refers to 11:12:13 of the first or fifth day of any month of the year 2012, but only if that day is a Thursday or Friday. HTH, -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Tidbits after monday meeting, related to registry mapping extension => RFC5730
On Fri, Jul 20, 2018, at 23:36, Ben McIlwain wrote: > And in response to the original message ... booleans cannot have three > possible values! Thanks Ben, you were probably replying to: "* for domain:info you have the hosts boolean with 3 values, not all registries are supporting all 3 cases." which indeed even at 2:38 AM is sloppy, so let me try to rephrase that, even if I am sure that everyone fixed it already: in RFC5731 you have this explanation for a domain:info (so I should put that in the other thread in fact, mea culpa) " An OPTIONAL "hosts" attribute is available to control return of information describing hosts related to the domain object. A value of "all" (the default, which MAY be absent) returns information describing both subordinate and delegated hosts. A value of "del" returns information describing only delegated hosts. A value of "sub" returns information describing only subordinate hosts. A value of "none" returns no information describing delegated or subordinate hosts." (so in fact it is 4 values, not 3, even less a boolean I guess :-)) Not all registries accept all of these values (again you can argue they are not following the standard, I am not judging that in one way or another just letting people know what exists really today), so you might want to track that in the registry mapping. Sorry again for my sloppiness at 2:38 AM. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] New Version Notification for draft-gould-carney-regext-registry-00.txt
owed? > > JG - I know nothing of the use of , so I would be > interested to further understand it. RFC 5731 section 3.2.5: A element can be used within the element to remove authorization information. And associated schema: >From my notes, and except if it changed recently, .NO uses this feature. Related to passwords, I think there is nothing about the EPP one (client login). But you have things like that: - some registries mandate it to be changed on first login - some registries mandate it to be changed at least in some frequence (ex: each 183 days). -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Suggestion of work methodology?
Hello, This is a meta discussion on the way we work. So just exposing some ideas, if they could interest anyone. Feel free to participate in you want, here or in private. You may have seen this email on the DNSOP working group: https://mailarchive.ietf.org/arch/msg/dnsop/gQ0qju2MPDBz4R5KkRYMKL_ioeg which was prompted by the "Camel" presentation of the DNS at the previous IETF meeting, and similar interests in other working groups. The TLS WG seems to have gone into the same kind of questions/directions. Many points boil down to: not everything that can be done should be done. (and the future is difficult to predict, hence thinking of being able right at the beginning to cover all future use cases, specially those not documented/voiced, can be tricky at least or completely ending in the wrong direction at worst). And I think part of the low participation is caused by the following. Sometimes this working group receives drafts that clearly caters for a specific registry or registrar. This is all fine per se and the fact of discussing things in public should be welcomed and appreciated. However it may be difficult for the other participants to really understand the use case, as this may not be always very clear. So you either let it go, or try to understand it, or try to offer comments on the proposition to make it more generic, which could be completely going an opposite route from the initial needs. Should every EPP extension used by only one registry be standardized through an RFC? Especially a "Proposed Standard" one? I am not sure about that. It is good of course that an extension is documented and even follows some wireframe. This is the purpose of the EPP extensions registry I think, and should be enough for some cases. The guidance of the working group would be, besides the EPP experts review on the document to advise if this is of generic interest or not, so that documents really coming into the WG as adopted documents and later WGLC on them and such are really made in such a way they are deemed to be useful for the EPP community at large. For anything that is supposed to benefit the greater good I think that the Implementation Section should be mandatory, to be done before a WGLC, with at least 2 separate server implementations and 2 separate client implementations. (and ideally at least one client implementation capable to speak to the 2 servers ones). It is only when implementations start to exist that the finest details of the design can be tested, so their existence should be mandatory before pushing a document towards the "Proposed Standard" state. The corrolary being that the writers will have to find registries and registrars willing to implement their proposition, which is one way to show interest and consensus. It would help also I think if the concerned registries speak up and support the specific work. I know that we are all under a "one participant one voice" rule, but it is clear too that work is done for specific registries or registrars, or group of them (like gTLDs). And for the same reason if any registry thinks that some proposition goes completely in the other direction from what they do or plan to do, and even if they may not be required to implement the extension, it should be good if they speak up. It could help reshape the design to make sure it accomodate more cases. -- 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 Thu, Jun 14, 2018, at 11:22, Martin Casanova wrote: > While implementing, another idea came to mind, which I want to put to > discussion here: > > > > > > Command completed successfully; ack to dequeue > > > > urn:ietf:params:xml:ns:changePoll-1.0 > > Msg incomplete due to missing extURI at login > cmd! To fix include at epp/command/login/svcs/svcExtension/extURI > > > > urn:ietf:params:xml:ns:secDNS-1.1 > > Msg incomplete due to missing extURI at login > cmd! To fix include at : epp/command/login/svcs/svcExtension/extURI > First on a technical level, replying to registrar basically "fix your client", is not really something nice, nor what registries should be doing. Notifications are external to registrars, they can appear without any action triggered by them so basically you are filling their "inbox" with some external messages they may or may not care about, and then you are taxing them of being bad because they can not read all messages, and maybe they would not like to. Some registrars may wish, for their own reasons, not to support some extensions and then at the same time you can not have one message in their queue that blocks all others after. But more important, on a technical level, I believe the spirit of RFC5730 is that value/extValue element appears for *error messages*, that is all having code 2000 or more. Hence they would not fit for a 1301 return code. Also note: A element that identifies a client-provided element (including XML tag and value) that caused a server error condition. => a client-provided element... the message you describe is in the response of a poll command by a client, and this poll command has none of that data you put in the element of the server reply. So while I see the underlying idea, I think you are bending RFC5730 quite a lot to achieve it. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt
On Thu, Jun 14, 2018, at 15:12, Gould, James wrote: > We can consider alternative authentication options if there is a > concrete proposal and the proposal does provide a security enhancement. It has alreay been proposed to be able to use non-plain passwords authentication > I > reviewed the RFCs that you referenced (SASL and PRECIS) and I don’t see > anything in them that defines an alternative authentication mechanism > for EPP. SASL define a framework to be able to easily handle various authentication meachinism, like plain and hashed password at the same time. This allows for more extensibility. PRECIS define a framework to deal with "internationalized" strings in application, and this covers both usernames and passwords. It gives idea on how to define a profile (and I still remain unconvinced of the need to remove space from the passwords accepted for EPP, again because it is not a password that a human will use). I believe they both could be useful starting block (as they exist and are IETF standards) if these parts needs to be changed/enhanced in EPP. Incidently, when they are more and more discussions around the subject of "how could a third party, like a DNS provider, mandated in some way by the registrant be able to do changes on the domain on its behalf without having to rely on the registrar", that SASL also handle OAUTH-types of authentication... > Creating additional authentication options in EPP may result > in less security, so it would be good to understand what security aspect > needs to be fixed prior to creating additional options. You never replied on the case of non-plain password authentication. Can you share how it results on less security, and why the *possibility* (then it is up to the registry to use it or not) of providing it is not useful to consider? Case in point for example: having it makes handling logging in a simpler way as password does not need to be specifically searched and obfuscated then for security reasons. People looking at logs in both sides would not be able to gain any knowledge of the password used. -- Patrick Mevzek p...@dotandco.com ___ 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 Thu, May 31, 2018, at 05:13, Ryan Finnesey wrote: > we have been keen to architect the system that will interact > between the Registries and the Registrar to run within the public cloud. > Azure and or AWS. We had a discussion the other day about using Azure > Functions but had to quickly rule it out because EPP requirement on TCP > Sockets. Azure Functions only support http as a protocol . > > Has there been any conversation about the Registries using REST? There has been in the past, see my earlier email in the thread. But noone implemented anything in that regard, from what I know. Also, it would be sad if the problem comes only from the fact that the use of come cloud is needed. I would provide maybe 2 ideas: - see Google GAE Proxy used for Nomulus because they have the exact same problem: the underlying App Engine supports only HTTP(S) so they needed a proxy from TCP/700 and TCP/43 (but the whois problem is kind of solved if you switch to RDAP) - the .BE registry "recently" migrated all their systems in the cloud too (AWS) so there is at least this solution that works. See https://www.dnsbelgium.be/en/news/first-european-cctld-cloud -- 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 Mon, Jul 16, 2018, at 21:08, Martin Casanova wrote:
> To be clear the domain info response will be sent just without the
> DNSSec part. Therefore a not DNSSec interested registrar will just not
> see the DNSSec configuration but all the rest of the domain info
> resData. I don't see a problem with that.
Here is the problem as already exposed: you may have registrars that do not
want to deal
with DNSSEC on a philosophical principle. They may want to specifically not try
to
transfer a currently DNSSEC enabled domain to them, because they know it will
break
resolution and they do not want to handle the customer saying that they broke
the domain.
Besides using the DNS, in your case, this registrar has no way to know in
advance
that the transfer will be a problem. And I suspect telling them 'Please be
DNSSEC
accredited with us and login with secDNS extension' will fall on a deaf ear.
> In case he is DNSSec enabled but still logs in without this extension he
> will get a failure with error message similar to “Not allowed to
> transfer DNSSec Domain” when trying to transfer a DNSSec domain to him.
What happens for a non-DNSSEC enabled registrar (and hence not using secDNS on
login)
when he tries to transfer to him a DNSSEC-enabled domain?
Is this refused?
Also to leave the discussion on track, this DNSSEC part of domain:info response
was only
one example of the same problem ("unhandled namespaces") outside of the poll
messages,
because I think the problem is global and we should tackle it globally (or not
at all
and leave it at the current status quo).
--
Patrick Mevzek
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
[regext] Tidbits after monday meeting, related to registry mapping extension
https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry Multiple subjects were covered and I had to input some data, so I will be doing different topics by replying to this email so that they are threaded together. You may wish to read all of them for context before replying to any. I only took a quick read of some documentation I currently have on hand for some registries, and this is far from exhaustive. I am not putting the registry names as I do not think that changes anything, but you will have to trust my word that I am not making up cases. Otherwise, the registry that recognize themselves could also speak up and say if they would deploy this extension. Like I said, to be a success, this extension needs to be widespread. It needs to be made in such a way that it can encompass very different cases. And for the one point specifically raised (control over the contact IDs, while the RFC may say there are completely under control of registrar, in practice for many ccTLDs registries it is the registry that choose the ID at creation, irrespective to what the registrar asks for), it needs to be easy to derive it separately in an extension for deviations from base. In fact, here is a generic comment: I think there is already things belonging in an extension that are indeed in the base document, so that should be split. For example, about contact types, while it is obvious that there are other ones on the wild, RFC5731 defines only 3, and not "custom". So custom should be dropped from core document. Same for privacy/proxy these concepts are not in RFC5733, and should be handled in extensions. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Tidbits after monday meeting, related to registry mapping extension => RFC5730
Specific points related to RFC5730: * clTRID is optional; but some registries make it mandatory * some registries do not allow some commands, like contact:transfer being not implemented (this is very frequent) or even sometimes contact:check (especially if registrars do not control their IDs), or other operations. Should that be specified somehow? * for domain:info you have the hosts boolean with 3 values, not all registries are supporting all 3 cases. * also, some commands, like updates may always be asynchronous (return code 1001), should that be specified? * for authInfo: : The OPTIONAL regular expression used to validate the domain object authorization information value. I do not think again that a regext will solve all problems. For example some registries say: with at least one uppercase and one digit and one "special" character. This is hard to express in a regex as the position does not matter. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Tidbits after monday meeting, related to registry mapping extension => HOST
* some registries allow, in domain:create, either attributes or objects for host. One might say this is against the core EPP specification, so do we want to treat it? * some registries do not allow all possible values for IP addresses. For example one is saying that it will refuse any IP provided if it is in RFC 1918 or 3330 or 3927 or 4193 or 3879. Of course other registries may have the same exclusion list or another. So that should be expressed. * one registry has this: at most 4 IP addresses but at least one IPv4 if some are provided. Which means you can not solve this even by just min+max for both IPv4 or IPv6 Because IPv4 min is 1 if IPv6 is present, otherwise 0. You can not say min=0 always because then it will allow a set with only one IPv6 address, which the registry disallow. * again around operations possible/not possible, one registry says for example: host:name can not be updated if it would then become a glue without any IP or become an external host with an IP. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Tidbits after monday meeting, related to registry mapping extension => IPR
I discovered this myself just before the meeting when preparing it but Scott also clearly mentioned it during the meeting (thanks for that): there is currently an IPR on this extension, with the case of "details will be provided later". You may recall that we were in a similar case for the keyRelay extension, and it got delayed because at some point noone knew anymore who was waiting on what and then discussions were needed to decide if going through or still waiting on the full IPR. I would prefer if the same situation does not repeat itself, so I am just wondering what can be done to make that going smoothly? -- 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 Thu, Jun 14, 2018, at 16:04, Gould, James wrote: > This approach looks good to me. It has the advantage of providing the > unhandled information in an element that is meant for machine processing > instead of using the element that’s meant is meant to be > human readable. The other advantage is that the contents of the > element is not processed by the XML parser (e.g., > processContents=”skip”), meaning it would not cause an XML parser error. > > This approach could include the entire unhandled extension block without > causing client-side parsing or unmarshalling issues. This "could" should be a "must", otherwise a registrar has no way to just download the message for later consumption without having the need to login will all possible extensions. Again please take into account this example that exists today: some registries restrict the extensions can be used on login, because some may be related to specific accredition, like secdns. So some registrars may not even be able to put some extensions there, but may get notifications with messages using these exceptions, as they do not control what kind of messages they get and some may appear due to actions from other parties, like other registrars or the registry itself. But like I said all of this still quite bends the RFC5730 spirit I think where value/extValue should be mostly for errors and value should reference a client provided element, which is not the case in these examples. This latest idea from Martin and you is probably the best one we discussed about as of yet, and if I could get convinced to add myself on the consensus for it, I am still uneasy by how it uses RFC5730 structures. -- 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 Mon, Jul 16, 2018, at 17:41, Patrick Mevzek wrote: > This is indeed more pragmatic. But all this mechanism to define which > messages to accept > will be outside the EPP protocol and this WG. But please also remember that if we want to tackle this problem in a generic way (and also taking care of different servers and clients strategies regarding handling of namespaces and inline/offline parsing and use) it is not limited to a single extension (the thread started long ago with changePoll) nor in fact limited to poll messages. Imagine registrar A wanting to request a transfer from registrar B. In some registries it means that regitrar A can do a domain:info on the domain, with the authInfo to get access to all details, and specifically the contacts. But a domain can have a secDNS part in the domain:info reply. What happens if the registrar A did not login with the secDNS extension (maybe this case does not exist in gTLDs where DNSSEC is mandatory but again we have other registries cases to take into account)? Should the domain:info return an error? Return everything as is? Return everything but the secDNS part? The last case is the worst to me: some registrars may like not to support DNSSEC at all (and hence will not log in at all, or you have other cases where registries mandate specific tests to be "DNSSEC" accredited so it may not even be possible to log in with secDNS extension even if the registrar would like to) but, and especially for this, being able to detect beforehand if some client is trying to transfer to them a domain using DNSSEC, that they would like to refuse transferring. Of course the above is only one example with a domain:info and the secDNS extension but I am sure we can find others. This illustrates I think the distinction I made in earlier messages and the different semantic I attach to extensions listed as login: for me they are those that the client announce it will use. Of course, it has no control over messages or objects he is not the origin or the sponsor, all cases where other namespaces may appear. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WGLC redux: REGEXT working group charter
On Fri, Aug 31, 2018, at 21:31, James Galvin wrote: > Please respond to this message on the mailing list and indicate your > support or questions regarding this charter. "updates" should be "updated" I think. And I still think it is too broad, especially "Data formats for files" (which files? what data? why the format needs a specification and a working group?). "Registry mapping" and "Registry transition" will probably seem obscure to anyone outside of the working group. I am myself not even sure what it covers or not. -- Patrick Mevzek p...@dotandco.com ___ 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 <p...@dotandco.com> 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] 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 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
[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
[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
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
pecific 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 systems too: do they have notifications? If so, where? (because registrars may not poll on OT systems so it may make sense to publish OT 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] 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-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
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] 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
[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-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] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)
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
Re: [regext] [Ext] regarding adopting new documents and milestones
On Mon, Oct 29, 2018, at 21:21, Andrew Newton wrote: > Perhaps priority should be given to those I-Ds with running code. This is one of the point I mage in my July message: https://mailarchive.ietf.org/arch/msg/regext/DuitffLvC4Q5RR32AnN1yDEUEYg Running code is useful/needed but maybe too high a barrier for an I-D to become a working group document. It can happen during its life I guess, but more important for me would be to have at least 2 completely separate *registries* implementation, which then could be a good idea of something that was in my July message. In short, not all extensions may become used by more than one registry. As sad as it may be for registrars (if the extension solves a generic issue that happens elsewhere or could benefit elsewhere), it is the state we are in. However in that, how much of working group energy should be devoted to that, and is the Proposed Standard path really necessary? Maybe just an addition of the extension in the EPP Extension Registry should be enough? There are a lot of extensions out there and discussed, and very few recorded in the extension registry. Basically only 3 registries took the effort to add their extensions there. And as said, sometimes an extension really tailored to one use case and one registry will need a lot of work to be more generic, and various feedback about needs of proper specification and taking care of interoperability might not be so much welcome in fact. So in summary I could say that I am not in favour of hardcoding any specific number of IDs to work on, but I would advise that 1) not all extensions need to become an RFC, being a proper ID with correct structure and registration in the extension registry is already a very good step and 2) for those wanting to be an RFC and before that wishing for the working group to work on, then they should really make sure to both display that the need spans multiple registries/registrars and that the document is really open to be updated to take into account more generic cases as needed as well as various implementation enhancements that are often only discovered when implementations are done. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-bundling-registration-06.txt - Impact of DNSSEC?
On Tue, Oct 30, 2018, at 19:31, Mack, Justin wrote: > I see that most attributes are shared between domains in the bundle, > such as assigned nameservers. Does this mean that DS/DNSKEY information > is also shared between these domains? Not possible for DS data as the DS digest value is computed in part from the domain name. So even if using the same key to sign two domains, the DS values will be different. It is technically possible to share a given DNSKEY between multiple domains, but then it means their fate is cryptographically tied: one key compromission opens attacks to all of them. It is kind of choosing in the X.509 world if you do one certicate with X domains related or not on one side or on the other side doing X separate certificates each one with one domain. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] regarding adopting new documents and milestones
favor first documents that have been introduced on the list by their authors with clear explanations on the use case, that have implementations (at least started if not done already), that are generic (can apply to more than one registry easily) and that fix/enhance current behavior, before adding new behaviour. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] draft-ietf-regext-bundling-registration and characters representation
On Sun, Nov 4, 2018, at 13:59, Jiankang Yao wrote: >Your suggestion is very good. RFC7997 is an informational RFC, and > shows a direction. Not just a direction but possible things right now. Because other formats than text are possible now, like PDF. >Because the popular form of RFC is TXT, the TXT can not display non > ASCII very well. No, see RFC 7990 and 7995. >I can use the natvie unicode characters in draft, but many readers > will not display it correctly. The RFC cited says how things can be dealt with and the difference between the txt and PDF format for example. If someone has to deal with internationalization and hence is interested by your document, I guess he knows how to deal with that and properly display characters. >According to my current understanding, U+ is still the proper > way to be easily understood by most readers. I still feel your document to be difficult to read, just because of that. Things like: xn--fsq270a.example are not easy, besides being invalid XML. (I pity the document shepherd that will need to validate all XML snippets, this can NOT be just copied and pasted in some validtor) Which is exactly why the RFC7997 says that directly using the unicode characters as is is permissible in examples. >Many years ago, IETF EAI WG also discussed this related issue. >I still do not see which rfc uses the natvie unicode characters > directly. RFC8187 for one. >If possilbe, I may suggest to add some texts in the draft, which says > "in future, the natvie unicode characters instead of U+ notation are > suggested to use in the document" As outlined, it is not in the future (hence this sentence is not necessary), you can do it today already with RFC7997 guidance. If you do not want to do it, then I do not recommend adding such a sentence. And if you want to do it (apply RFC 7997 guidance) then you do not need this sentence either, but you can put one explaining that examples contains unicode characters, as permissible by section such and such of RFC7997. If your draft goes further in the process, I guess this issue will come again at various last calls and reviews. -- 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-15.txt
On Sun, Nov 4, 2018, at 16:35, Roger D Carney wrote: > A small updated was needed, implementers found the "standard" attribute > was not at the correct level in the commandDataType. As expected and said previously, this late addition without any clear support from anyone except the initial requestor, will create interoperability problems. I will not rehash the issue but I am not surprised and I will continue to think that this fee extension misses the goal of best compromise possible between features really needed by a common subset of actors and the complexity needed to encode all those features. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Picking XML namespaces
On Mon, Nov 5, 2018, at 06:29, Gould, James wrote: > Yes, there are Production systems in place that use this namespace. > Scoping the namespace at this stage would cause Production > interoperability issues. Let me know if you need any additional > information. I completely disagree with this reasoning, irrespective of the specific document as I would say the same thing for the same case. This is only a draft, implementations are bound to change. As a developer myself, I implemented a lot of drafts in their early versions, for "free" and it would have been the same thing for "just" namespaces changes. So I can totally understand the difficulty to change things at the last time, but then it is the game to play if we want global standards, their limits and edge cases appear when they are really implemented (hence the Implementation Status section in documents), and hence implementations are bound to need updates when the standard "matures" and gets input from other parties. Current deployments should not forbid making the document better and hence creating at the end a better standard for everyone. If we do otherwise we just re-inforce something that I am seeing more and more which is converting this working group as a pure rubberstamping "authority" were documents come already finished or close to finished or not really open to changes because it won't suit the original author. It would be then too easy for anyone to come and then just refuse changes because it is already deployed as is. Also, it was always sold that the greeting+login exchange enables client and server to autonegiotate extensions, including those that change the namespace (like the fee one with many different namespaces - even if just different on the version part - and many registries today exposing more than one). Now what I can agree on is why setting the line at this document instead of any other one? As soon as we have identified a problem regarding the namespaces used, I think all documents not yet being an RFC should be modified to adhere to the new convention. I see no sensible reason to say to do it for some but not others. So my opinion is to change the namespace everywhere and not let any new extenson become an RFC without this change. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Comments about draft-gould-casanova-regext-unhandled-namespaces
Hello James and Martin, While implementing this specification, the following occured to me: §3 says: : A formatted human-readable message that indicates the reason the unhandled namespace data was not returned in the appropriate location of the response. The formatted reason SHOULD follow the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: NAMESPACE-URI "not in login services", where NAMESPACE-URI is the unhandled XML namespace like "urn:ietf:params:xml:ns:domain-1.0" for [RFC5731]. However RFC5730 §2.6 defines the node as such: A element containing a human-readable message that describes the reason for the error. The language of the response is identified via an OPTIONAL "lang" attribute. If not specified, the default attribute value MUST be "en" (English). It is then my opinion that the following would be technically allowed: ... urn:X not in login services Which is kind of strange because "urn:X not in login services" is certainly not in a French language. Or at least there should be a mention in the specification to explicitely forbid that. But more globally, the problem comes from the fact that is supposed to be human-readable message and as such should not convey a format for machine readable content. In fact, reading above in RFC5730 yields: A element that identifies a **client-provided** element (including XML tag and value) that caused a server error condition. I emphasized the **client-provided** which is not the case in all examples of your draft since all content there are coming from the server directly. Note that the "top" (outside of ) is defined slightly differently because it is: Zero or more OPTIONAL elements that identify a client- provided element (including XML tag and value) or other information that caused a server error condition. Note the: **or other information that caused a server error condition**. (even if technically the two nodes are defined by the same type) So in short, while I believe your draft is the best solution on the table for now if we want to do something about unhandled namespaces, I still think that with this form it abuses RFC 5730 a little too much... Also, since the client may need to be able to detect this case, I would recommend that support for this way of handling unknown namespaces is exposed at greeting time by a specific namespace. Otherwise the client has to use a regular expression on the reason. For all the above reasons, I would recommend the following changes to the specification: - the server has to specify his support for this extension in , by a specific namespace - instead of using and abusing its part, I advise the following: 1) either use 2 , one with what you put currently in , the other with the current 2) or use a single but with such a structure (to be refined with a proper namespace) urn:ietf:params:xml:ns:secDNS-1.1 3) or simplifying things with an attribute: (use namespaceNotInLogin instead of unhandleNamespace or anything else, if prefered) This is based on the fact that is defined as such: I kind of prefer the last version as it is the simpler one, but option 2 could fit too. Option 1 seems clunky because it hardcodes dependency between two nodes. Using a "top" instead of inside also solves the problem above of the fact that they are defined differently and the value inside of extValue should convey only client-provided content, while the "top" value can be more freeform. Thanks for your consideration. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-change-poll-10: (with DISCUSS and COMMENT)
On Mon, Dec 10, 2018, at 11:48, Gould, James wrote: > Section 2.3 > > "CSR" could expand to either "Customer Support Representative" or > "Certificate Signing Request" for some people. I don't know if there's > better name to suggest. > > JG - I believe the reference to "CSR" as "Customer Support > Representative" is pretty standard in the domain name industry with no > confusion to a "CSR" in the digital certificate industry. I kind of disagree but it is a minor point and I believe that the context provides enough disambiguitation. There is in general possible confusion as there is overlap between the domain name business and the digital certificate issuance business at least for two reasons: many certificates are DV so they directly depend on domain names and multiple domain name registries and registrars are also Certificate Authorities. However I really do not see also what we gain by the acronym we could as well put Customer Service Representative or Support Agent or Customer Care or whatever, in full, instead of an acronym there, so that the example is complete. > Section 2.4 > > I don't know if it's worth saying anything that would remind recipients of > their (non-?)obligation to accept time values that correspond to leap > seconds, but IIRC we've seen cases in the past of software that chokes > when > presented with leap-second timestamps. > > JG - This is standard boilerplate text in the EPP RFCs (RFC 5731 - > 5733) that include timestamps, and I'm not aware of any EPP software > issues associated with leap-second timestamps that warrants a reminder > in this EPP draft. I agree with James, for better or worse, no other EPP documents go into such territories as leap-second and this specification is no more "time" oriented than the others so it makes no specific sense to start here talking about leap seconds. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] list of documents to consider for working group adoption
o devote the little personal time I have to try implementing some of the documents that I find interesting (as implementing them raise all sorts of feedback) instead of reading completely external documents and then compare all of them together while not be sure to even look at some of them again in the future. Which is why I won't vote for any document right now because some are not passing the preconditions I listed and for others I can not guarantee working on them at any level so I believe my vote to be kind of worthless for the working group. But that is just me so if the process above works for everyone as is, do not loose time trying to convince me, it is not very important, and I can always comment later on the documents I would have time to work on. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] =?UTF-8?Q?Re:__Tidbits_after_monday_meeting, _related_to_registry?= mapping extension => DOMAIN
Hello, Back in July I sent group of emails with details seen in the wild that may need to be in the extension, or not. I am only responding to this one about the form in fact and not the content, because I was kind of surprised by various points in the replies I got like: > How many registries do this (many, some, few, or just one)? This is the first time I see a count of registries being asked to finally decide how to implement something or not. In fact recent cases show that we did exactly the opposite: for the fee extension and the very late inclusion of the standard attribute, if we summarize things we had - one registrar asking for it but not really promoting it nor participating on discussions - 2 registries saying basically "it is optional, we will not use it, so we are neutral to it" - one client side implementor (me) and one registry saying: this lacks a true purpose and is dangerous for interoperability. Result: it passed, the attribute was added! Based on that, I do not see why now we should dictate what goes in or not based on how it is used in the wild. I think you have basically three options: - encode only exactly what core EPP documents allow - try to filter things and define those used often enough to warrant being included from those used by only "1" registry that are put aside and would need an extension - put everything in. We are not doing 1) because last time I read the specification there are things in it that are clearly not in EPP core documents (like "custom" contact types). We seem to be trying to do 2) which is very dangerous because it leads to questions like above and if you match that by the very low amount of exchanges on this list, I really fail to see how we can make sure to take the proper decisions as a group. And of course, by "extension" 3) would be as well difficult to reach. But at least my position is basicall a 2) without treating some cases as second class citizen just because they are rare or further away from "pure" EPP. Of course it would help if each registry participated and were champions for their own cases but obviously we are not there nor will we be in a short future. Or otherwise we really do 1) but then multiple things will need to be removed (custome contact types, privacy/proxy, etc. I listed some in my previous emails). So, I do not think it is useful for this working group that I reply extensively on each point, where I mostly detailed what is happening in the wild currently, that we may like or dislike on an engineer level, but then the question I think is really how much we want this "registry policy" extension to be implemented by many registries, and not by the ones closer to "standard" EPP. Even if I may not have phrased things good enough, I hope the above will have succeeded in trying to raise awareness about the so many different cases in the wild and the need to try to "accomodate" if we want success both in term of numbers of implementations and avoiding fragmentations (where multiple extensions exist to do exactly the same thing in fact). -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting 2018OCT16
On Tue, Nov 27, 2018, at 11:28, Gould, James wrote: > > * Ensure that the hostAddr model of RFC 5731 is supported > > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/1>* > > *Discussion* > > * In the case of a zone that supports domain:hostAddr instead of > > domain:hostObj, > > No. It is not "instead". > Have a look at the example on page 19 of some registry documentation > at > https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf [..] > The purpose of draft-gould-carney-regext-registry and the policy > extensions is to define the policies around the SHOULDs, MAYs, and > options included in extension RFCs, I-Ds, custom extensions, and to > define the server-specific policies. If a registry chooses not to > follow the MUSTs in the extensions, that is their choice. They can > define their custom, non-compliant policies in a server-specific policy > extension of draft-gould-carney-regext-registry. Custom policy > extensions can be created that define system-level and zone-level > policies that don't need to go through the IETF. There is no need to > attempt to address non-compliant policies in the standards track I-Ds. I think you are missing the point I try to raise here. It is of course very easy to dismiss this specific case (but there are tons of others) because the RFC says "MUST", and the case does not follow it, so it is deemed invalid per RFC specifications and can then be ignored. Technically, yes. But this has consequences for the future. First, let me reiterate how important I think this extension is, and I wished we had it many years ago already. With it, life of registrars would be tremendously easier. Which would then also make registries life easier. **IF** (and this is the big if and the core of my point) it gets implemented, and this is where I fear problems, even more so because there is basically no discussion on this list from other registries about it. For me the future can morph into the following cases: 1) a registry is fully conformant with all RFCs and hence could implement this extension as is without difficulties. It is just a policy/business/marketing case to decide to implement it or not, the specification is not a barrier 2) registries that decided not to implement it anyway, for whatever reasons and case they are in 3) registries that DO NOT respect all RFCs to the letter and/or are in cases not handled by this new extension and that are thinking about implementing it or not. If they want to implement it they have the choice: a) either to change their policies and business rules that either contradicts core EPP documents or are incompatible with the extension as written right now b) or to create **another** EPP extension just to code for the differences between the kind of policies that can be encoded in your extension and the registry policies that do not fit in The above are facts, the below are my assumptions. - case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall in this case - case 2 is irrelevant for this discussion as nothing we discuss can change that - case 3 is the interesting point, and my assumption is that this will group basically all ccTLDs, and my further assumptions are that of course registries will not change their policies just because this extension is not tailored to them (so 3a will mostly be empty) and I doubt many will go the length of writing a new extension just to codify their policies (so 3b will be negligible) [BTW 3b introduces again the exact same problem we had with EPP extensions since the beginning: fragmentation. Multiple registries have a "trade" operation for example. To encode that as policy, there is a risk each one drafting an extension for it, and then you come back to the case of multiple non-interoperable extensions that do the same things which is a nightmare] So I fear that at the end we will have something beautiful that caters for all the generic/simple cases, but that left out all complicated cases, and hence the implementation will not be widespread. The fact that no registry claimed to be willing to implement it or to write an extension for their own policy is very troublesome for me. But maybe it happened in private or will be announced in the future. -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] REGEXT Interim Meeting 2018OCT16
On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote: > * I still don’t like the use of the elements as a > “flexible mechanism to share data between the client and the server”. There are many registries going this route, and it is very sad, even if easy to understand why. It voids any usefulness of the schema attached to the (XML) documents, and basically will only need to interoperability problem because this content will not be described in an automated content, and relying on human documentation is not enough. > * The schedule format to use with the > element > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/5>* > *Discussion* > * This particular topic is not straight forward, since we need a > condensed mechanism to define the batch schedules. I do not see why "condensed". We are in XML land already, which is not known for its small size anyway so why would there be a need here to condense things? > * Ensure that the hostAddr model of RFC 5731 is supported > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/1>* > *Discussion* > * In the case of a zone that supports domain:hostAddr instead of > domain:hostObj, No. It is not "instead". Have a look at the example on page 19 of some registry documentation at https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf You will see that both options can cohabit. Now, I already know that some people will say: this is not allowed per EPP specifications. But besides that it is important to be clear on the purpose of this extension: being as "pure" and perfect as possible, with the hope that non-conforming current cases will then suddenly decide to fix their thing in order to be able to use it, or being as inclusive as possible so that as many registries as possible are using it as is. I think this extension can be very useful if many registries implement it. If it is only a few, it will not give registrars a lot of useful data, and hence they will not profit from it. And I do not think that "not conforming" cases will feel the need to change just to be able to implement this extension. This is a generic point I may try to raise again later in the past threads about this extension. It is an important question, that is itself tied to the amount of energy devoted to each extension, which extension becomes working group documents and which extensions really solve problem of more than one registry and hence may have the chance to be implemented by a sizeable chunk of current players. HTH, -- Patrick Mevzek ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Comments about draft-gould-casanova-regext-unhandled-namespaces
On Sun, Jan 6, 2019, at 23:02, Patrick Mevzek wrote: > Hello James and Martin, Thanks for your attention and comments to my email. I see that we are in disagreement, so I think it is not useful for me to go again over all points. My opinion still remains that at this stage the draft abuses RFC 5730 too much and needlessly because I believe there are other options that makes it more in line with RFC 5730 spirit. In fact I believe that in its current form it will create an interoperability problem and hence it lowers its chance to be implemented by a huge range of registrars. It is not a problem for registries of course because on server side it is just the matter of creating some new nodes at some location in the frame. But a registrar has to handle many different EPP servers, some will have implemented this extension, some not. And hence why it does create an interoperability problem? Because: 1) if this extension is not explicitely announced at greeting time by the server (something you seem to be very much against) 2) and if you continue to use extValue/value + reason, the latter being for human consumption but you add a format in it with a SHOULD and opening problem with the lang attribute 3) THEN a client (registrar) CAN NOT depend on the reason content to find out about the namespace concerned (because the reason content is only a SHOULD and the specification does not deal with a lang different than "en" ... all points showing again that you should not abuse a human targeted field to put machine readable data in it) so it can instead just parse the content of and take the first namespace it sees there BUT it has no idea if the content of is something coming from your extension or something completely different (coming from the initial definition of in RFC5730) so it will need to use heuristics instead of relying on determinism, or just drop all of it and not caring at all. It is important for a client to understand if what comes back in value/extValue is due to what it has sent (original description of the fields in RFC 5730) or something completely different as in your extension. In its current form your extension leaves no way for a registrar to know without doubt in which case it is. I think that creating this interoperability problem just adds one more problem on top of the problem of handling unknown namespaces. Hence I will not be in favor of this extension going forward in its current shape. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Minor comment on draft-gould-regext-login-security-02
Dear James and Matthew, A minor point while implementing it (finished, will announce it soon). If a new "long" password is presented, it is exchanged in the node. However for events, among the list of possible values for type you have: newPw I see no reason for the different casing. I recommend that the type value is also newPW or, to be more in line with other values to just spell it out in full, hence "newPassword". In fact I have found out one instance of for the XML node, so maybe a leftover of a previous change. You may want to double check all examples/quotes of the node name to have the proper casing. Also since all 3 nodes are optional under loginSec you may wish to specify that the extension should be sent only if at least one of the node is present beneath it. Or what the server should reply if it gets only an empty root node. (and on a more philosophical level, I feel userAgent should not be defined in this extension because it has nothing to do with passwords and could be useful just be itself; it is useless however to create an extension just for it so I can understand why putting it there, but it is still bundling things together that are not related) And maybe provide some advice about downgrade, what about the following chain of events: - change of password using loginsec:newPW for a long password - but then change back to short password using pure newPW without the loginSec part. Allowed? Recommended? -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] DOODLE: select your documents
Hello Alexander, On Thu, Jan 3, 2019, at 03:25, Alexander Mayrhofer wrote: > Jim, > > thanks for posting that - i've made my choices. > > For the record, I share most if not all of your rant Alexander. 1) I am sad to see this working group and the IETF being a rubberstamp for documents discussed elsewhere and coming here explicitely as stated just to get an RFC number. This is wrong on so many levels and could even be seen as an abuse of IETF. I do not think the working group should put time and energy on those documents. In most cases they can as well be an individual submission or just stay as a specification added to the EPP Extension registry. If people decided to work on them in other venues, then they should just finish "standardization" of them in those other venues, switching to the IETF at the last minute just for an RFC number is certainly not the expected way to work. The aim of the working group in my mind is to try defining extension that works for the widest use cases possible accross many registrars and registries. The community is not so big so splitting work in many venues even lowers the chance the results will have enough reviews to make them as generic and globally useful as possible. Like Alexander stated, the impact of each specification (does it concern one specific case or is it useful for all EPP servers in the world) could or should be taken into account when deciding to work on X instead of Y. Otherwise we get only a very thin short time frame gain of having RFC for numerous "standardized" extensions where no real consensus will exist on them, some will overlap or even contradict themselves which will in the long term make the current situation regarding deployed extensions on servers even more complex that it is nowadays (and it is complex enough), hence making registrars even more complicated which in turn constrains registries to not be able to easily run new services because registrars will not implement them, etc. 2) I would have much prefered seeing people coming on this exact mailing-list and stating that they will support such and such documents by promising to work on them (reviewing, implementing, etc.) instead of an anonymous poll done on a remote site, whose results are difficult to interpret (is it interest in something being done? willingness to work on it? just showing that is seems to be important without any real interest in it? etc.). That would have shown real community support for some documents and provide a clear proof of interests later on for shepherd reviews and IETF-wide LC. For all these reasons I voluntarily did not participate in this polling, even if I clearly have my opinion on which documents are most useful to work on than others and which should get the WG attention or not. That is the end of my rant. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [gtld-tech] EPDP recommendations and EPP
On Fri, Mar 1, 2019, at 16:22, Roger D Carney wrote: > Thanks for the comments Patrick. I agree about the pollution of > placeholders and that is one reason why I think it can only be used as > a temporary solution. If this is implemented, it will become permanent and there will be nothing else replacing it later. > I am not sold on creating a "new object." Another way to do the same > intention, to me this will just get convoluted for implementers (look > here unless you should look over there). I do not feel that convoluted and even if it is the case we already have many of them: - host attributes vs host objects - secDNS keyData vs dsData etc. > To me this is just creating a > new mechanism to avoid fixing a problem in the current mechanism. There is no problem in current mechanism. ccTLDs are all "fine" with it. Right now we are discussing (in multiple places so that makes participating difficult) things that will only apply to gTLDs. I really do not want again to give everyone's impression that we are tailoring a protocol to a very specific case just because the major vocal interests are there. In short, if gTLDs need another contact model because the one in RFC5733 is not fitting today anymore, it seems the clearer and simpler to me to just define a new model for contacts. > I am not sure how improving RFC 5733 to be more flexible and data > privacy/protection aware is a detriment to anyone using EPP. Anyone > using 5733 needs to be acutely aware of data "processing" and would > greatly benefit from a more flexible technical solution. You can not "improve" RFC 5733. You will need to create a new namespace, like "contact-2.0" At which point it is quite the same for implementors because any client with multi registries need will need to handle both namespaces (you can not expect all registries, specially non gTLD ones, just moving to your new schema, even if it is a strict superset of previous ones, because they will have absolutely 0 reasons, technical or economical, to do the change), so if you have "contact-1.0" and "contact-2.0" namespaces to handle OR "contact-1.0" and "lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever) it is basically the same amount of work, but second option seems better to me for multiple reasons. And again, there is a huge non technical difference. If we give again the impression to change the EPP just to suite gTLD needs, we should not lament later on the state of EPP worldwide and why not everyone follows the standard to the letter, or best current practices, etc. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [gtld-tech] EPDP recommendations and EPP
On Tue, Mar 5, 2019, at 07:42, Gavin Brown wrote: > > Instead of updating RFC5733 I would suggest creating a new object, > > a "light (or shallow) contact" which is like a contact currently, just with > > less fields. > > Domains could use "full contacts" (the ones we know today) or light > > contacts (the new > > ones). > > I can't see how this would work. Let's say we define a new object > mapping for "light" contacts, with its own namespace, to be used with > just the element in domain objects. > > Could such contacts be used with domains without an update to RFC 5731? Probably not, but so what? You can not just "update" RFC 5733, you will need to write a new one, with a new XML schema, and hence you will need to update RFC 5731 as well. > Could a registrar determine whether a given contact object was a "full" > contact or a "light" without performing an command? Since the registrar created the object in the first place, I do not see the issue there. Also, there may not be a need to mix contacts: a registry can decide to use only one form (if the new schema is constructed in such a way to fit all contacts cases), and hence there is no question. > I think this would cause a huge amount of confusion and pain. Using placeholders creates even more confusion and just tries to go around a schema that does not fit its use anymore... > Furthermore, my research[1] indicates that the "one-to-many" > relationship between domains and contacts that is implicit in EPP does > not reflect reality, And yet in the nearly 20 years of existence of EPP noone came forward to propose working on this... Please do not use the result of an ICANN *policy* to change the protocol while implying this is needed for all EPP servers as it is was an EPP deficiencies in the first place. It may well be an EPP deficiency and if so it needs to be tackled separately, but that is really not the correct channel at this point. > If we're going to write a new RFC just for technical contacts then I I never suggested "just for technical contacts". On the contrary, if defined properly, the schema could be used, in place, for all contacts. For some registries, like gTLDs ones bound by specific contracts, they could then just use those instead of the current "contact-1.0" ones. > would suggest that it should define an extension to the domain object, > since that is (a) simpler for clients and servers to implement and (b) > more accurately maps to the way the data is represented and handled > outside of EPP. This would create even more confusion, as clearly today the hosts as objects vs hosts as attributes is one of the major pain point of any registrar (again, one has to try to be in registrar shoes, for a registry everything is simple, it has one case to handle, its own, and it can often forget that its registrar have other cases to handle too, so all the complexities finish on the registrars' shoulders) > > One has to keep remembering that EPP is not just used by gTLDs, so any > > change has to > > be done in such a way that it does not impact negatively any operation done > > outside > > of ICANN circles. > > It seems to me that updating RFC5733 would have a bigger impact outside > the gTLD world than either of the other options I've proposed: I am still waiting on non-gTLD registries to participate in the subject and to see how much they will be happy to see EPP changed for everyone *just because* ICANN enacted some new policy. > presumably many ccTLD registries rely on the the XML schema in RFC 5733 > to enforce their data collection policies, but if we change that schema, > and they unknowingly update their implementation, then their data > collection policy will be changed without them knowingly accepting it. You can not "change that schema". You need to create a new namespace. Besides, I have no idea what you mean. Registries policies on contact data go far beyond what is in the EPP schema, in the sense of validation done and constraints. You already have far more problematic issue like "id" being either ignored or just refused (while being mandatory in the schema), the "int" vs "loc" issue, the semantics of "update" on "postalAddr", etc. And again, if a new contact schema appears, registries that want it use it, those that want to keep the current contact-1.0 keep it, and all is fine (besides the complexities for registrars, but obviously they will have to deal with it in any way, placeholders introduce their own complexities as they will be hardcoded in every piece of code, so that the value is not offered for edition for example, etc.) -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [gtld-tech] EPDP recommendations and EPP
On Fri, Mar 1, 2019, at 15:39, Roger D Carney wrote: > I think I am in agreement with most people on this, that option 3 (or > C, whatever it is called) is the best short term solution “define a > "convention" that allows the and elements to contain > placeholder values, such as: - and XX which pose > no data protection issues”. I am completely againts such placeholders. While they are the easy fast solution, they just pollute databases with useless data. Instead of updating RFC5733 I would suggest creating a new object, a "light (or shallow) contact" which is like a contact currently, just with less fields. Domains could use "full contacts" (the ones we know today) or light contacts (the new ones). One has to keep remembering that EPP is not just used by gTLDs, so any change has to be done in such a way that it does not impact negatively any operation done outside of ICANN circles. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
