Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
Hello Roger,
On 25/04/2017 23:40, Roger D Carney wrote:
> One topic that was discussed in Chicago (and not resolved) was on the
> concept of “premium names” and what is returned from the server if no fee
> extension was passed into the . Many thought to be more “backwards
> compatible”/”user friendly”, especially for those registrars that do not
> and may not be participating in the allocation of “premium names”, that
> the server should respond as unavailable. Others expressed that if it is
> available then the server should respond available. Please share your
> thoughts on the list on this topic and if this draft should even try to
> account for this concept.
I believe that responding "unavailable" is the best option here.
The rationale is: if a without special precautions (such
as an extension) yields "available", then a subsequent
without special precautions should succeed. Conversely, if a
fails because the registrar didn't indicate (via the fee
extension, for example) that he's aware of the higher price of the
domain, then a corresponding should yield "not available"
if that check doesn't somehow indicate the same awareness of the higher
price. The semantics of that check result are: "You can't create the
domain name just like that, more data is needed."
Now I'm aware that the fee extension isn't currently suited for
signalling awareness of a higher price in a , but that's OK
since it provides other means to find out under which circumstances a
for a checked domain will succeed.
As a side note, I should mention that in our own TANGO registry system,
the pricing of premium domains is closely tied to *launch phases* (since
launch phases readily provide a means to classify domains, we decided to
use it rather than creating an additional proprietary classification). A
registrar may create a premium domain by either providing correct fee
information *or* specifying the correct launch phase when creating the
domain.
In this setup, a for a premium domain yields "unavailable"
without specification of that launch phase, but it yields "available" if
the correct launch phases is passed along in the command.
Yet I'm aware that this kind of signalling ("what if I created that
domain specifying these fees in an extension?") isn't within the fee
extension's scope at the moment, and it probably won't need to be.
Best regards,
Thomas
--
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200
D-44227 Dortmund E-Mail: supp...@tango-rs.com
Germany
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-hollenbeck-regext-rdap-object-tag-03.txt
On 18 Apr 2017, at 8:46, Hollenbeck, Scott wrote: -Original Message- From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Tuesday, April 18, 2017 8:34 AM To: i-d-annou...@ietf.org Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-rdap-object-tag- 03.txt … The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object-tag/ This version includes a description of the Verisign Labs implementation of the proposed tagging scheme. With this update I would like to ask the chairs to ask the WG to consider adoption of this document. I would also like to ask anyone else who might have implemented the scheme to let me know so that I can add more information to the Implementation Status section. Scott, Thanks for this. We will certainly add it to the list of documents to be considered for adoption. Recall from our last meeting at the IETF, our AD does not want us to add any more documents to our milestone list until we moved some things along. The actions we had agreed to at the meeting were as follows (summarized from the minutes of the last meeting): 1. With respect to the escrow documents (which were also being considered for adoption), the authors should revive the documents as individual contributions and add an implementation status section. We will consider these documents again after we complete the next two actions. 2. The WG needs to revisit its current list of extensions and clearly indicate those that are to be standards track and those that just need an entry in the extension registry. 3. For those documents intended for the standards track, poke the editors to see if there is going to be forward progress or consider withdrawing the documents. Once we have cleaned up our current list of adopted documents, then we can consider adding new documents. Jim ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-hollenbeck-regext-rdap-object-tag-03.txt
> -Original Message- > From: James Galvin [mailto:gal...@elistx.com] > Sent: Wednesday, April 26, 2017 9:39 AM > To: Hollenbeck, Scott > Cc: regext@ietf.org > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-hollenbeck-regext-rdap- > object-tag-03.txt > > > > On 18 Apr 2017, at 8:46, Hollenbeck, Scott wrote: > > >> -Original Message- > >> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf > >> Of internet-dra...@ietf.org > >> Sent: Tuesday, April 18, 2017 8:34 AM > >> To: i-d-annou...@ietf.org > >> Subject: [EXTERNAL] I-D Action: > >> draft-hollenbeck-regext-rdap-object-tag- > >> 03.txt > >> … > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-object- > >> tag/ > > > > This version includes a description of the Verisign Labs > > implementation of the proposed tagging scheme. > > > > With this update I would like to ask the chairs to ask the WG to > > consider adoption of this document. I would also like to ask anyone > > else who might have implemented the scheme to let me know so that I > > can add more information to the Implementation Status section. > > Scott, > > Thanks for this. We will certainly add it to the list of documents to be > considered for adoption. > > Recall from our last meeting at the IETF, our AD does not want us to add > any more documents to our milestone list until we moved some things along. > > The actions we had agreed to at the meeting were as follows (summarized > from the minutes of the last meeting): > > 1. With respect to the escrow documents (which were also being considered > for adoption), the authors should revive the documents as individual > contributions and add an implementation status section. We will consider > these documents again after we complete the next two actions. > > 2. The WG needs to revisit its current list of extensions and clearly > indicate those that are to be standards track and those that just need an > entry in the extension registry. > > 3. For those documents intended for the standards track, poke the editors > to see if there is going to be forward progress or consider withdrawing > the documents. > > Once we have cleaned up our current list of adopted documents, then we can > consider adding new documents. Great! Let's see some movement on these actions! Scott ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
Hi Roger, thanks for version 0.17! This one should solve most of our "registrar" issues (Hopefully, some registries plan to implement this version soon). Some thoughts to open questions: * Premium Domain Availability without Fee-Ext. I would also vote to respond with "unavailable". The status "premium" of a domain could be understood in a similar way to the domain status reserved, blocked or registered. Without using the fee extension, it's not possible to register such names, therefore they're "unavailable" for the registrar just like reserved names. If we don't want to use the Fee-Ext. for a specific registry (because of contractual reasons or something else), we're not interested in the availability of premium names which we can't/won't register anyway. Second thought: From a registry's perspective, I understand a name is always "available" if it is not registered, blocked or reserved, independent of any fees. But, ;) since EPP is a personalized communication protocol (client needs to login and register extensions to use), then responses should be personalized to the client. For a client not using the fee extension, a premium name is technically "unavailable". * in check responses The last weeks a question regarding the element came up a couple of times. is a child of since version 0.13, therefore section 3.7. should be clarified. Is an attribute of a specific fee or an object? There are some misunderstandings, especially before version 0.13, which describes "class" as a child of . Several discussions with registries pointed out, that they understand as "attribute" of the object. This results in conditions where a domain has a premium create but a standard renewal fee to be both tagged with "premium", because an object can only have one value of the same attribute. As an example (from section 3.7): "The element which appears in responses is used to indicate the classification of an object." should be changed to something like "... the classification of a command fee". As a registrar, we need to know if a "command fee" (not an object) is premium (e.g. premium) or standard, if one wants to respond standard fees at all. Responding standard fees are in fact unnecessary, btw. Thanks, Andreas Am 25.04.2017 um 23:40 schrieb Roger D Carney: > Good Afternoon, > > > > Here is the update draft document. This should include all of the agreed upon > changes from the Chicago meeting (biggest change was the simplification of > the call). > > > > One topic that was discussed in Chicago (and not resolved) was on the concept > of “premium names” and what is returned from the server if no fee extension > was passed into the . Many thought to be more “backwards > compatible”/”user friendly”, especially for those registrars that do not and > may > not be participating in the allocation of “premium names”, that the server > should respond as unavailable. Others expressed that if it is available then > the server should respond available. Please share your thoughts on the list > on this topic and if this draft should even try to account for this concept. > > > > Please let me know if you have any questions. > > > > > > Thanks > > Roger > > > > > > -Original Message- > From: regext [mailto:regext-boun...@ietf.org] On Behalf Of > internet-dra...@ietf.org > Sent: Tuesday, April 25, 2017 4:31 PM > To: i-d-annou...@ietf.org > Cc: regext@ietf.org > Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.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 of the > IETF. > > > > Title : Registry Fee Extension for the Extensible > Provisioning Protocol (EPP) > > Authors : Roger Carney > > Gavin Brown > > Jothan Frakes > > Filename: draft-ietf-regext-epp-fees-03.txt > > Pages : 33 > > Date: 2017-04-25 > > > > Abstract: > >This document describes an Extensible Provisioning Protocol (EPP) > >extension mapping for registry fees. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03 > > > > > > 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.iet
[regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/
At the last IETF meeting, it was agreed in the REGEXT meeting that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard: Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ Ulrich Wisser is the document shepherd and in that role he agrees the document is ready for publication. If any working group member objects to the publication of this document please respond on the list by close of business everywhere, Wednesday, 3 May 2017. If there are no objections the document will be submitted to the IESG. Thanks, Antoin and Jim WG Co-Chairs ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Milestones changed for regext WG
Changed milestone "Submit for publication draft-ietf-eppext-idnmap", added draft-ietf-eppext-idnmap to milestone. Changed milestone "Submit for publication "CIRA IDN EPP Extension"", added draft-cira-regext-idn to milestone, removed draft-wilcox-cira-idn-eppext from milestone. URL: https://datatracker.ietf.org/wg/regext/about/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
