Re: [regext] DOODLE: select your documents
Thanks to all those who have indicated their document preferences. This is a reminder we will close the poll tomorrow, so if you haven’t indicated your preferences please do so. Currently, there is a small set at the top of the list. More than 5, although there is a pretty clear top two. Thanks again, Jim On 21 Dec 2018, at 11:13, James Galvin wrote: Please take the time to select the documents you support for advancement in this working group. https://doodle.com/poll/6nyguby3yr8dx9cp Please select from 1-5 documents. If you click once in the box a green check mark will appear. Use this to indicate support for a document. If you click twice in the box a yellow check mark in parentheses will appear. You may use the yellow check mark to indicate support that is a lower priority than a green check mark. For your convenience I have included the list of documents and their links below. This selection process will remain open for 3 weeks, until 11 January 2019. Enjoy your holiday season! See you all next year! Jim DOCUMENTS TO CONSIDER Registry Reporting Repository https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/ Registry Reporting Structure https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/ Domain Fee Report https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/ Registry Transaction Report https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/ Registry Domain Inventory Report https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/ Registry Domain Drop Report https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report Registry Unavailable Domain Report https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/ Registry Maintenance Notifications https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/ Unhandled Namespaces https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces Data Set File Format https://datatracker.ietf.org/doc/draft-gould-regext-dataset/ Login Security https://datatracker.ietf.org/doc/draft-gould-regext-login-security/ Federated Authentication for RDAP https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ RDAP Partial Response https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/ RDAP Search https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/ RDAP Reverse Search https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/ RDAP Sorting and Paging https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-sorting-and-paging/ Registry Data Escrow Specification https://datatracker.ietf.org/doc/draft-arias-noguchi-registry-data-escrow/ Domain Name Registration Data (DNRD) Objects Mapping https://datatracker.ietf.org/doc/draft-arias-noguchi-dnrd-objects-mapping/ Third Party DNS Operator to Registrar/Registry https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ Validate https://datatracker.ietf.org/doc/draft-ietf-regext-validate/ Verification Code https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] I-D Action: draft-ietf-regext-verificationcode-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions WG of the IETF. Title : Verification Code Extension for the Extensible Provisioning Protocol (EPP) Author : James Gould Filename: draft-ietf-regext-verificationcode-06.txt Pages : 38 Date: 2019-01-10 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension for including a verification code for marking the data for a transform command as being verified by a 3rd party, which is referred to as the Verification Service Provider (VSP). The verification code is digitally signed by the VSP using XML Signature and is "base64" encoded. The XML Signature includes the VSP signer certificate, so the server can verify that the verification code originated from the VSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-verificationcode/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-regext-verificationcode-06 https://datatracker.ietf.org/doc/html/draft-ietf-regext-verificationcode-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-verificationcode-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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] 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
